Table of Contents

Configuring Asynchronous Lines and Interfaces

Asynchronous Call Queueing by Role

Configuring Asynchronous Serial Traffic Over UDP

Configuring and Managing Integrated Modems

1- and 2-Port V.90 Modem WICs for Cisco 2600 and Cisco 3600 Series Multiservice Platforms

Call Tracker show Commands Extensions

Cisco NM-8AM-V2 and NM-16AM-V2 Analog Modem Network Modules with V.92

MICA and NextPort Modem Tech-Support Command Additions

PIAFS Wireless Data Protocol Version 2.1 for Cisco MICA Modems

V.92 and V.44 Support for Digital Modems

V.92 Modem on Hold for Cisco AS5300 and Cisco AS5800 Universal Access Servers

V.92 Modem on Hold for Cisco AS5350, Cisco AS5400, and Cisco AS5850 Universal Gateways and Cisco AS5800 Universal Access Servers

V.92 Quick Connect for Cisco AS5300 and Cisco AS5800 Universal Access Servers

V.92 Quick Connect for Cisco AS5350, Cisco AS5400, and Cisco AS5850 Universal Gateways and Cisco AS5800 Universal Access Servers

V.92 Reporting Using RADIUS Attribute v.92-info

Configuring and Managing Cisco Access Servers and Dial Shelves

Configuring and Managing External Modems

Modem Signal and Line States

Creating and Using Modem Chat Scripts

Cisco Modem User Interface

Modem Script and System Script Support in Large-Scale Dial-Out

Leased and Switched BRI Interface for ETSI NET3

ISDN BCAC and Round-Robin Channel Selection Enhancements

Configuring Virtual Asynchronous Traffic over ISDN

Configuring Modem Use over ISDN BRI

Configuring X.25 on ISDN

Configuring X.25 on ISDN Using AO/DI

Configuring ISDN on Cisco 800 Series Routers

Cisco IOS Software Feature Removal

Configuring ISDN PRI

Dialing Number Enhancement

ISDN BCAC and Round-Robin Channel Selection Enhancements

Configuring ISDN Special Signaling

Configuring Network Side ISDN PRI Signaling, Trunking, and Switching

Preparing to Configure DDR

Configuring Legacy DDR Spokes

Configuring Legacy DDR Hubs

Configuring Peer-to-Peer DDR with Dialer Profiles

Dialer Map VRF-Aware for an MPLS VPN

Dialer Persistent

PPPoE Client DDR Idle-Timer

Redial Enhancements

Rotating Through Dial Strings

Configuring Dialer CEF

CEF Support for Dialer Profiles on Cisco 7500 Routers

Configuring Snapshot Routing

Reliable Static Routing Backup Using Object Tracking

Configuring Dial Backup for Serial Lines

Configuring Dial Backup Using Dialer Watch

Dialer Watch Connect Delay

VRF Aware Dialer Watch

Configuring Dial Backup with Dialer Profiles

ISDN Backup in MPLS Core

Configuring Cisco Easy IP ..

Configuring Virtual Template Interfaces

Multiclass Multilink PPP

Configuring Asynchronous Callback

Configuring PPP Callback

Configuring ISDN Caller ID Callback

Configuring BACP

Configuring an IP Local Pools Holdback Timer

Configuring per-User Configuration

Configuring Resource Pool Management

Configuring Wholesale Dial Performance Optimization

Large-Scale Dial-Out

Dial-Out DS0 Level Trunk Group

L2TP Large-Scale Dial-Out

L2TP Large-Scale Dial-Out per-User Attribute via AAA

Modem Script and System Script Support in Large-Scale Dial-Out

Large-Scale Dial-Out (LSDO) VRF Aware

Peer Pool Backup

Dial Networking Business Applications

Enterprise Dial Scenarios and Configurations

Telco and ISP Typical Dial Scenarios and Configurations

Modem Initialization Strings

Overview of Dial Interfaces, Controllers, and Lines

Configuring Asynchronous Lines and Interfaces

This chapter describes how to configure asynchronous line features in the following main sections:

- How to Configure Asynchronous Interfaces and Lines

- How to Configure Other Asynchronous Line and Interface Features

- Configuration Examples for Asynchronous Interfaces and Lines

Perform these tasks, as required, for your particular network.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

How to Configure Asynchronous Interfaces and Lines

To configure an asynchronous interface, perform the tasks described in the following sections as required:

- Configuring a Typical Asynchronous Interface (As required)

- Creating a Group Asynchronous Interface (As required)

- Configuring Asynchronous Rotary Line Queueing (As required)

- Configuring Autoselect (As required)

Configuring a Typical Asynchronous Interface

To configure an asynchronous interface, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Brings up a single asynchronous interface and enters interface configuration mode.

Step 2

Provides a description for the interface.

Step 3

Specifies an IP address.

Step 4

Enables PPP to run on the asynchronous interfaces in the group.

Step 5

Enables the router to pass routing updates to other routers over the AUX port configured as an asynchronous interface.

Step 6

Places a line into dedicated asynchronous mode using Serial Line Internet Protocol (SLIP) or PPP encapsulation.

Step 7

Specifies that dial-on-demand routing (DDR) is to be supported.

Step 8

Configures a serial interface to call one or multiple sites or to receive calls from multiple sites.

Step 9

Controls access by configuring an interface to belong to a specific dialing group.

Step 10

variable with a specified authentication list name.1

Step 11

Return to global configuration mode.

1.To create a string used to name the following list of authentication methods tried when a user logs in, refer to the aaa authentication ppp command. Authentication methods include RADIUS, TACACS+, and Kerberos.

1.To create a string used to name the following list of authentication methods tried when a user logs in, refer to the aaa authentication ppp command. Authentication methods include RADIUS, TACACS+, and Kerberos.

The “Interface and Line Configuration Examples” and “Asynchronous Interface As the Only Network Interface Example” sections later in this chapter contain examples of how to configure an asynchronous interface.

Monitoring and Maintaining Asynchronous Connections

This section describes the following monitoring and maintenance tasks that you can perform on asynchronous interfaces:

- Monitoring and maintaining asynchronous activity

- Debugging asynchronous interfaces

- Debugging PPP

To monitor and maintain asynchronous activity, use the following commands in privileged EXEC mode as needed:

Command

Purpose

Returns a line to its idle state.

Displays parameters that have been set for extended BOOTP requests.

Displays statistics for asynchronous interface activity.

]

Displays the status of asynchronous line connections.

To debug asynchronous interfaces, use the following debug command in privileged EXEC mode:

Command

Purpose

}

Displays errors, changes in interface state, and log input and output.

To debug PPP links, use the following debug commands in privileged EXEC mode as needed:

Command

Purpose

Enables debugging of PPP protocol negotiation process.

Displays PPP protocol errors.

Displays PPP packets sent and received.

Displays errors encountered during remote or local system authentication.

Creating a Group Asynchronous Interface

Create a group asynchronous interface to project a set of core protocol characteristics to a range of asynchronous interfaces. Configuring the asynchronous interfaces as a group saves you time. Analog modem calls cannot enter the access server without this configuration.

To configure a group asynchronous interface, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Brings up a single asynchronous interface and enters interface configuration mode.

Step 2

Router(config-if)# ip unnumbered loopback number

Configures the asynchronous interfaces as unnumbered and assigns the IP address of the loopback interface to them to conserve IP addresses.2

Step 3

Router(config-if)# encapsulation ppp

Enables PPP to run on the asynchronous interfaces in the group.

Step 4

Router(config-if)# async mode interactive

Configures interactive mode on the asynchronous interface.

Step 5

Router(config-if)# ppp authentication chap pap list-name

variable with a specified authentication list name.3

Step 6

Router(config-if)# peer default ip address pool poolname

Assigns dial-in clients IP addresses from an address pool.4

Step 7

Router(config-if)# no cdp enable

Disables the Cisco Discovery Protocol (CDP) on the interface.

Step 8

Router(config-if)# group-range low-end-of-range high-end-of-range

Specifies the range of asynchronous interfaces to include in the group, which is usually equal to the number of modems you have in the access server.

Step 9

Router(config-if)# exit

Returns to global configuration mode.

2.You can also specify the Ethernet interface to conserver address space. In this case, enter the ip unnumbered ethernet 0 command.

2.You can also specify the Ethernet interface to conserver address space. In this case, enter the ip unnumbered ethernet 0 command.

3.To create a string used to name the following list of authentication methods tried when a user logs in, refer to the aaa authentication ppp command. Authentication methods include RADIUS, TACACS+, and Kerberos.

3.To create a string used to name the following list of authentication methods tried when a user logs in, refer to the aaa authentication ppp command. Authentication methods include RADIUS, TACACS+, and Kerberos.

4.To create an IP address pool, refer to the ip local pool global configuration command.

4.To create an IP address pool, refer to the ip local pool global configuration command.

The “Group and Member Asynchronous Interface Examples” section later in this chapter contains an example of how to configure a group interface.

Verifying the Group Interface Configuration

command:

Router# show interface async 1

Async1 is up, line protocol is up

modem(slot/port)=1/0, csm_state(0x00000204)=CSM_IC4_CONNECTED, bchan_num=18

modem_status(0x0002): VDEV_STATUS_ACTIVE_CALL.

Hardware is Async Serial

Interface is unnumbered. Using address of FastEthernet0 (10.1.1.10)

MTU 1500 bytes, BW 115 Kbit, DLY 100000 usec, rely 255/255, load 1/255

Encapsulation PPP, loopback not set, keepalive not set

DTR is pulsed for 5 seconds on reset

LCP Open

Open: IPCP

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters never

Queueing strategy: fifo

Output queue 0/5, 0 drops; input queue 1/5, 0 drops

5 minute input rate 37000 bits/sec, 87 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

31063 packets input, 1459806 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

33 packets output, 1998 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

commands and then send a call into the access server. Interpret the output and make configuration changes accordingly.

- undebug all

- debug ppp negotiation

- debug ppp authentication

- debug modem

- debug ip peer

Router# undebug all

All possible debugging has been turned off

Router# debug ppp negotiation

PPP protocol negotiation debugging is on

Router# debug ppp authentication

PPP authentication debugging is on

Router# debug modem

Modem control/process activation debugging is on

Router# debug ip peer

IP peer address activity debugging is on

Router# show debug

General OS:

Modem control/process activation debugging is on

Generic IP:

IP peer address activity debugging is on

PPP:

PPP authentication debugging is on

PPP protocol negotiation debugging is on

Router#

*Mar 1 21:34:56.958: tty4: DSR came up

*Mar 1 21:34:56.962: tty4: Modem: IDLE->READY

*Mar 1 21:34:56.970: tty4: EXEC creation

*Mar 1 21:34:56.978: tty4: set timer type 10, 30 seconds

*Mar 1 21:34:59.722: tty4: Autoselect(2) sample 7E

*Mar 1 21:34:59.726: tty4: Autoselect(2) sample 7EFF

*Mar 1 21:34:59.730: tty4: Autoselect(2) sample 7EFF7D

*Mar 1 21:34:59.730: tty4: Autoselect(2) sample 7EFF7D23

*Mar 1 21:34:59.734: tty4 Autoselect cmd: ppp negotiate

*Mar 1 21:34:59.746: tty4: EXEC creation

*Mar 1 21:34:59.746: tty4: create timer type 1, 600 seconds

*Mar 1 21:34:59.786: ip_get_pool: As4: using pool default

*Mar 1 21:34:59.790: ip_get_pool: As4: returning address = 172.20.1.101

*Mar 1 21:34:59.794: tty4: destroy timer type 1 (OK)

*Mar 1 21:34:59.794: tty4: destroy timer type 0

*Mar 1 21:35:01.798: %LINK-3-UPDOWN: Interface Async4, changed state to up

*Mar 1 21:35:01.834: As4 PPP: Treating connection as a dedicated line

*Mar 1 21:35:01.838: As4 PPP: Phase is ESTABLISHING, Active Open

*Mar 1 21:35:01.842: As4 LCP: O CONFREQ [Closed] id 1 len 25

*Mar 1 21:35:01.846: As4 LCP: ACCM 0x000A0000 (0x0206000A0000)

*Mar 1 21:35:01.850: As4 LCP: AuthProto CHAP (0x0305C22305)

*Mar 1 21:35:01.854: As4 LCP: MagicNumber 0x64E923A8 (0x050664E923A8)

*Mar 1 21:35:01.854: As4 LCP: PFC (0x0702)

*Mar 1 21:35:01.858: As4 LCP: ACFC (0x0802)

*Mar 1 21:35:02.718: As4 LCP: I CONFREQ [REQsent] id 3 len 23

*Mar 1 21:35:02.722: As4 LCP: ACCM 0x000A0000 (0x0206000A0000)

*Mar 1 21:35:02.726: As4 LCP: MagicNumber 0x00472467 (0x050600472467)

*Mar 1 21:35:02.726: As4 LCP: PFC (0x0702)

*Mar 1 21:35:02.730: As4 LCP: ACFC (0x0802)

*Mar 1 21:35:02.730: As4 LCP: Callback 6 (0x0D0306)

*Mar 1 21:35:02.738: As4 LCP: O CONFREJ [REQsent] id 3 len 7

*Mar 1 21:35:02.738: As4 LCP: Callback 6 (0x0D0306)

*Mar 1 21:35:02.850: As4 LCP: I CONFREQ [REQsent] id 4 len 20

*Mar 1 21:35:02.854: As4 LCP: ACCM 0x000A0000 (0x0206000A0000)

*Mar 1 21:35:02.854: As4 LCP: MagicNumber 0x00472467 (0x050600472467)

*Mar 1 21:35:02.858: As4 LCP: PFC (0x0702)

*Mar 1 21:35:02.858: As4 LCP: ACFC (0x0802)

*Mar 1 21:35:02.862: As4 LCP: O CONFACK [REQsent] id 4 len 20

*Mar 1 21:35:02.866: As4 LCP: ACCM 0x000A0000 (0x0206000A0000)

*Mar 1 21:35:02.870: As4 LCP: MagicNumber 0x00472467 (0x050600472467)

*Mar 1 21:35:02.870: As4 LCP: PFC (0x0702)

*Mar 1 21:35:02.874: As4 LCP: ACFC (0x0802)

*Mar 1 21:35:03.842: As4 LCP: TIMEout: State ACKsent

*Mar 1 21:35:03.842: As4 LCP: O CONFREQ [ACKsent] id 2 len 25

*Mar 1 21:35:03.846: As4 LCP: ACCM 0x000A0000 (0x0206000A0000)

*Mar 1 21:35:03.850: As4 LCP: AuthProto CHAP (0x0305C22305)

*Mar 1 21:35:03.854: As4 LCP: MagicNumber 0x64E923A8 (0x050664E923A8)

*Mar 1 21:35:03.854: As4 LCP: PFC (0x0702)

*Mar 1 21:35:03.858: As4 LCP: ACFC (0x0802)

*Mar 1 21:35:03.962: As4 LCP: I CONFACK [ACKsent] id 2 len 25

*Mar 1 21:35:03.966: As4 LCP: ACCM 0x000A0000 (0x0206000A0000)

*Mar 1 21:35:03.966: As4 LCP: AuthProto CHAP (0x0305C22305)

*Mar 1 21:35:03.970: As4 LCP: MagicNumber 0x64E923A8 (0x050664E923A8)

*Mar 1 21:35:03.974: As4 LCP: PFC (0x0702)

*Mar 1 21:35:03.974: As4 LCP: ACFC (0x0802)

*Mar 1 21:35:03.978: As4 LCP: State is Open

*Mar 1 21:35:03.978: As4 PPP: Phase is AUTHENTICATING, by this end

*Mar 1 21:35:03.982: As4 CHAP: O CHALLENGE id 1 len 26 from "nas-1"

*Mar 1 21:35:04.162: As4 CHAP: I RESPONSE id 1 len 26 from "krist"

*Mar 1 21:35:04.170: As4 AUTH: Started process 0 pid 47

*Mar 1 21:35:04.182: As4 CHAP: O SUCCESS id 1 len 4

*Mar 1 21:35:04.186: As4 PPP: Phase is UP

*Mar 1 21:35:04.190: As4 IPCP: O CONFREQ [Not negotiated] id 1 len 10

*Mar 1 21:35:04.194: As4 IPCP: Address 172.20.1.2 (0x0306AC140102)

*Mar 1 21:35:04.202: As4 CDPCP: O CONFREQ [Closed] id 1 len 4

*Mar 1 21:35:04.282: As4 IPCP: I CONFREQ [REQsent] id 1 len 40

*Mar 1 21:35:04.282: As4 IPCP: CompressType VJ 15 slots CompressSlotID (0x02

06002D0F01)

*Mar 1 21:35:04.286: As4 IPCP: Address 0.0.0.0 (0x030600000000)

*Mar 1 21:35:04.290: As4 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)

*Mar 1 21:35:04.294: As4 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)

*Mar 1 21:35:04.298: As4 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)

*Mar 1 21:35:04.302: As4 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)

*Mar 1 21:35:04.306: As4 IPCP: O CONFREJ [REQsent] id 1 len 10

*Mar 1 21:35:04.310: As4 IPCP: CompressType VJ 15 slots CompressSlotID (0x02

06002D0F01)

*Mar 1 21:35:04.314: As4 CCP: I CONFREQ [Not negotiated] id 1 len 15

*Mar 1 21:35:04.318: As4 CCP: MS-PPC supported bits 0x00000001 (0x1206000000

01)

*Mar 1 21:35:04.318: As4 CCP: Stacker history 1 check mode EXTENDED (0x11050

00104)

*Mar 1 21:35:04.322: As4 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP

*Mar 1 21:35:04.326: As4 LCP: (0x80FD0101000F12060000000111050001)

*Mar 1 21:35:04.330: As4 LCP: (0x04)

*Mar 1 21:35:04.334: As4 IPCP: I CONFACK [REQsent] id 1 len 10

*Mar 1 21:35:04.338: As4 IPCP: Address 172.20.1.2 (0x0306AC140102)

*Mar 1 21:35:04.342: As4 LCP: I PROTREJ [Open] id 5 len 10 protocol CDPCP (0x82

0701010004)

*Mar 1 21:35:04.342: As4 CDPCP: State is Closed

*Mar 1 21:35:05.186: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async4, ch

anged state to up

*Mar 1 21:35:05.190: As4 PPP: Unsupported or un-negotiated protocol. Link cdp

*Mar 1 21:35:05.190: As4 PPP: Trying to negotiate NCP for Link cdp

*Mar 1 21:35:05.194: As4 CDPCP: State is Closed

*Mar 1 21:35:05.198: As4 CDPCP: TIMEout: State Closed

*Mar 1 21:35:05.202: As4 CDPCP: State is Listen

*Mar 1 21:35:06.202: As4 IPCP: TIMEout: State ACKrcvd

*Mar 1 21:35:06.206: As4 IPCP: O CONFREQ [ACKrcvd] id 2 len 10

*Mar 1 21:35:06.206: As4 IPCP: Address 172.20.1.2 (0x0306AC140102)

*Mar 1 21:35:06.314: As4 IPCP: I CONFACK [REQsent] id 2 len 10

*Mar 1 21:35:06.318: As4 IPCP: Address 172.20.1.2 (0x0306AC140102)

*Mar 1 21:35:07.274: As4 IPCP: I CONFREQ [ACKrcvd] id 2 len 34

*Mar 1 21:35:07.278: As4 IPCP: Address 0.0.0.0 (0x030600000000)

*Mar 1 21:35:07.282: As4 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)

*Mar 1 21:35:07.286: As4 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)

*Mar 1 21:35:07.286: As4 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)

*Mar 1 21:35:07.290: As4 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)

*Mar 1 21:35:07.294: As4 IPCP: O CONFNAK [ACKrcvd] id 2 len 34

*Mar 1 21:35:07.298: As4 IPCP: Address 172.20.1.101 (0x0306AC140165)

*Mar 1 21:35:07.302: As4 IPCP: PrimaryDNS 172.20.5.100 (0x8106AC140564)

*Mar 1 21:35:07.306: As4 IPCP: PrimaryWINS 172.20.5.101 (0x8206AC140565)

*Mar 1 21:35:07.310: As4 IPCP: SecondaryDNS 172.20.6.100 (0x8306AC140664)

*Mar 1 21:35:07.314: As4 IPCP: SecondaryWINS 172.20.6.101 (0x8406AC140665)

*Mar 1 21:35:07.426: As4 IPCP: I CONFREQ [ACKrcvd] id 3 len 34

*Mar 1 21:35:07.430: As4 IPCP: Address 172.20.1.101 (0x0306AC140165)

*Mar 1 21:35:07.434: As4 IPCP: PrimaryDNS 172.20.5.100 (0x8106AC140564)

*Mar 1 21:35:07.438: As4 IPCP: PrimaryWINS 172.20.5.101 (0x8206AC140565)

*Mar 1 21:35:07.442: As4 IPCP: SecondaryDNS 172.20.6.100 (0x8306AC140664)

*Mar 1 21:35:07.446: As4 IPCP: SecondaryWINS 172.20.6.101 (0x8406AC140665)

*Mar 1 21:35:07.446: ip_get_pool: As4: validate address = 172.20.1.101

*Mar 1 21:35:07.450: ip_get_pool: As4: using pool default

*Mar 1 21:35:07.450: ip_get_pool: As4: returning address = 172.20.1.101

*Mar 1 21:35:07.454: set_ip_peer_addr: As4: address = 172.20.1.101 (3) is redun

dant

*Mar 1 21:35:07.458: As4 IPCP: O CONFACK [ACKrcvd] id 3 len 34

*Mar 1 21:35:07.462: As4 IPCP: Address 172.20.1.101 (0x0306AC140165)

*Mar 1 21:35:07.466: As4 IPCP: PrimaryDNS 172.20.5.100 (0x8106AC140564)

*Mar 1 21:35:07.470: As4 IPCP: PrimaryWINS 172.20.5.101 (0x8206AC140565)

*Mar 1 21:35:07.474: As4 IPCP: SecondaryDNS 172.20.6.100 (0x8306AC140664)

*Mar 1 21:35:07.474: As4 IPCP: SecondaryWINS 172.20.6.101 (0x8406AC140665)

*Mar 1 21:35:07.478: As4 IPCP: State is Open

*Mar 1 21:35:07.490: As4 IPCP: Install route to 172.20.1.101

*Mar 1 21:35:25.038: As4 PPP: Unsupported or un-negotiated protocol. Link cdp

*Mar 1 21:36:12.614: tty0: timer type 1 expired

*Mar 1 21:36:12.614: tty0: Exec timer (continued)

*Mar 1 21:36:25.038: As4 PPP: Unsupported or un-negotiated protocol. Link cdp

*Mar 1 21:37:25.038: As4 PPP: Unsupported or un-negotiated protocol. Link cdp

*Mar 1 21:38:25.038: As4 PPP: Unsupported or un-negotiated protocol. Link cdp

*Mar 1 21:39:25.038: As4 PPP: Unsupported or un-negotiated protocol. Link cdp

*Mar 1 21:40:25.038: As4 PPP: Unsupported or un-negotiated protocol. Link cdp

*Mar 1 21:41:25.038: As4 PPP: Unsupported or un-negotiated protocol. Link cdp

*Mar 1 21:42:25.038: As4 PPP: Unsupported or un-negotiated protocol. Link cdp

*Mar 1 21:43:25.038: As4 PPP: Unsupported or un-negotiated protocol. Link cdp

Configuring Asynchronous Rotary Line Queueing

The Cisco IOS Asynchronous Rotary Line Queueing feature allows Telnet connection requests to busy asynchronous rotary groups to be queued so that users automatically obtain the next available line, rather than needing to try repeatedly to open a Telnet connection. The Cisco IOS software sends a periodic message to the user to update progress in the connection queue.

This feature allows users to make effective use of the asynchronous rotary groups on a Cisco router to access legacy mainframes or other serial devices with a limited number of asynchronous ports that might be used by a large number of users. Users that are unable to make a Telnet connection on the first attempt are assured of eventual success in an orderly process. They are no longer required to guess when a line might be available and to retry manually again and again.

Connections are authenticated using the method specified for the line configurations for the asynchronous rotary group. If a connection is queued, authentication is done prior to queueing and no authentication is done when the connection is later established.

Make sure you comply with the following requirements when configuring asynchronous rotary line queueing:

- Configure more virtual terminal lines than will ever be used by waiting asynchronous rotary connection attempts. Even when the queue is at its maximum, there must be at least one virtual terminal line available so that system operators or network administrators can use Telnet to access the router to show, debug, or configure system performance.

- When adding lines to a rotary group, all lines must be either queued or not queued. A mixture of queued and unenqueued lines in the same rotary group is not supported and can result in unexpected behavior.

- All lines within a queued rotary group need to use the same authentication method. Using different authentication methods within the same rotary group can result in unexpected behavior.

To configure asynchronous rotary line queueing, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Router (config)# line [ aux | console | tty | vty ] line-number [ ending-line-number ]

Starts line configuration mode on the line type and numbers specified.

Step 2

Router(config-line)# rotary group [ queued | round-robin ]

) linear port selection algorithm.

See the “Rotary Group Examples” section for configuration examples.

Verifying Asynchronous Rotary Line Queueing

To verify operation of asynchronous rotary line queueing, perform the following tasks:

- Use the show line command in EXEC mode to check the status of the vty lines.

- Use the show line async-queue command in EXEC mode to check the status of queued connection requests.

Troubleshooting Asynchronous Rotary Lines

commands in privileged EXEC mode to determine where the problem may lie:

- debug async async-queue

- debug ip tcp transactions

- debug modem

for information about these commands.

Monitoring and Maintaining Asynchronous Rotary Line Queues

To display queued lines and to remove lines from the queue, use the following commands in EXEC mode as needed:

Command

Purpose

Router# show line async-queue rotary-group

Displays which lines are queued.

Router# clear line async-queue rotary-group

argument is not specified, all rotary queues are removed.

Configuring Autoselect

Autoselect is used by the access server to sense the protocol being received on an incoming line and to launch the appropriate protocol. Autoselect can be used for AppleTalk Remote Access (ARA), PPP, or SLIP.

When using Autoselect, “login” authentication is bypassed, so if security is required, it must be performed at the protocol level, that is, the AppleTalk Remote Access Protocol (ARAP) or PPP authentication. SLIP does not offer protocol layer authentication.

To configure the Cisco IOS software to allow an ARA, PPP, or SLIP session to start automatically, use the following command in line configuration mode:

Command

Purpose

}

Configures a line to automatically start an ARA, PPP, or SLIP session.

command enables the Cisco IOS software to start a process automatically when a start character is received.

keyword, the username or password prompt appears without the need to press the Return key; thus “login” users will get a prompt right away without needing to press the Return key. While the username or password prompt is displayed, you can choose either to answer these prompts or to send packets from an autoselected protocol.

line configuration command.

Note When the autoselect command is used, the activation character should be set to the default Return, and exec-character-bits should be set to 7. If you change these defaults, the application cannot recognize the activation request.

See the “High-Density Dial-In Solution Using Autoselect and EXEC Control Example” section for an example that makes use of the autoselect feature.

Verifying Autoselect PPP

commands are enabled. As PPP calls pass through the access server, you should see this output.

When autoselect is used, “login” authentication is bypassed. If security is required, it must be performed at the protocol level (that is, ARAP or PPP authentication). SLIP does not offer protocol layer authentication.

22:21:02: TTY1: DSR came up

22:21:02: tty1: Modem: IDLE->READY

22:21:02: TTY1: Autoselect started

22:21:05: TTY1: Autoselect sample 7E

22:21:05: TTY1: Autoselect sample 7EFF

22:21:05: TTY1: Autoselect sample 7EFF7D

22:21:05: TTY1 Autoselect cmd: ppp default

22:21:05: TTY1: EXEC creation

%LINK-3-UPDOWN: Interface Async1, changed state to up

22:21:07: ppp: sending CONFREQ, type = 2 (CI_ASYNCMAP), value = A0000

22:21:07: ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 23BE13AA

22:21:08: PPP Async1: state = REQSENT fsm_rconfack(0xC021): rcvd id 0x11

22:21:08: ppp: config ACK received, type = 2 (CI_ASYNCMAP), value = A0000

22:21:08: ppp: config ACK received, type = 5 (CI_MAGICNUMBER), value = 23BE13AA

22:21:08: ppp: config ACK received, type = 7 (CI_PCOMPRESSION)

22:21:08: ppp: config ACK received, type = 8 (CI_ACCOMPRESSION)

22:21:08: PPP Async1: received config for type = 0x2 (ASYNCMAP) value = 0x0 acked

22:21:08: PPP Async1: received config for type = 0x5 (MAGICNUMBER) value = 0x2A acked

22:21:08: PPP Async1: received config for type = 0x7 (PCOMPRESSION) acked

22:21:08: PPP Async1: received config for type = 0x8 (ACCOMPRESSION) acked

22:21:08: ipcp: sending CONFREQ, type = 3 (CI_ADDRESS), Address = 172.16.1.1

22:21:08: ppp Async1: ipcp_reqci: rcvd COMPRESSTYPE (rejected) (REJ)

22:21:08: ppp Async1: Negotiate IP address: her address 0.0.0.0 (NAK with address 172.16.1.100) (NAK)

22:21:08: ppp: ipcp_reqci: returning CONFREJ.

22:21:08: PPP Async1: state = REQSENT fsm_rconfack(0x8021): rcvd id 0x9

22:21:08: ipcp: config ACK received, type = 3 (CI_ADDRESS), Address = 172.16.1.1

22:21:08: ppp Async1: Negotiate IP address: her address 0.0.0.0 (NAK with address 172.16.1.100) (NAK)

22:21:08: ppp: ipcp_reqci: returning CONFNAK.

22:21:09: ppp Async1: Negotiate IP address: her address 172.16.1.100 (ACK)

22:21:09: ppp: ipcp_reqci: returning CONFACK.

%LINEPROTO-5-UPDOWN: Line protocol on Interface Async1, changed state to up

Verifying Autoselect ARA

commands are enabled. As ARA version 2.0 calls pass through the access server, this output is displayed.

20:45:11: TTY3: DSR came up

20:45:11: tty3: Modem: IDLE->READY

20:45:11: TTY3: EXEC creation

20:45:11: TTY3: Autoselect(2) sample 1

20:45:11: TTY3: Autoselect(2) sample 11B

20:45:12: TTY3: Autoselect(2) sample 11B02

20:45:18: ARAP: ---------- SRVRVERSION ----------

20:45:19: ARAP: ---------- ACKing 0 ----------

20:45:19: ARAP: ---------- AUTH_CHALLENGE ----------

20:45:21: ARAP: ---------- ACKing 1 ----------

20:45:21: ARAP: ---------- AUTH_RESPONSE ----------

20:45:21: ARAP: ---------- STARTINFOFROMSERVER ----------

20:45:22: ARAP: ---------- ACKing 2 ----------

22:45:22: ARAP: ---------- ZONELISTINFO ----------

22:45:22: ARAP: ---------- ZONELISTINFO ----------

22:45:22: ARAP: ---------- ZONELISTINFO ----------

The following trace is for ARA version 1.0 calls:

22:31:45: TTY1: DSR came up

22:31:45: tty1: Modem: IDLE->READY

22:31:45: TTY1: Autoselect started

22:31:46: TTY1: Autoselect sample 16

22:31:46: TTY1: Autoselect sample 1610

22:31:46: TTY1: Autoselect sample 161002

22:31:47: ARAP: ---------- SRVRVERSION ----------

22:31:47: ARAP: ---------- ACKing 0 ----------

22:31:47: ARAP: ---------- AUTH_CHALLENGE ----------

22:31:47: ARAP: ---------- ACKing 1 ----------

22:31:47: ARAP: ---------- AUTH_RESPONSE ----------

22:31:47: ARAP: ---------- STARTINFOFROMSERVER ----------

22:31:48: ARAP: ---------- ACKing 2 ----------

22:31:48: ARAP: ---------- ZONELISTINFO ----------

22:31:48: ARAP: ---------- ZONELISTINFO ----------

22:31:49: ARAP: ---------- ZONELISTINFO ----------

How to Configure Other Asynchronous Line and Interface Features

This section describes the following asynchronous line and interface configurations:

- Configuring the Auxiliary (AUX) Port

- Establishing and Controlling the EXEC Process

- Enabling Routing on Asynchronous Interfaces

- Configuring Dedicated or Interactive PPP and SLIP Sessions

- Conserving Network Addresses

- Using Advanced Addressing Methods for Remote Devices

- Optimizing Available Bandwidth

Configuring the Auxiliary (AUX) Port

global configuration command.

. To enable the auxiliary port, use the following command in global configuration mode:

Command

Purpose

Enables the auxiliary serial DTE port.

You cannot use the auxiliary (AUX) port as a second console port. To use the AUX port as a console port, you must order a special cable from your technical support personnel.

On an access server, you can configure any of the available asynchronous interfaces (1 through 8, 16, or 48). The auxiliary port (labeled AUX on the back of the product) can also be configured as an asynchronous serial interface, although performance on the AUX port is much slower than on standard asynchronous interfaces and the port does not support some features.

illustrates why asynchronous interfaces permit substantially better performance than AUX ports configured as asynchronous interfaces.

Table 1 Differences Between the Asynchronous Port and the Auxiliary (AUX) Port

Feature

Asynchronous Interface

Auxiliary Port

Maximum speed

115200 bps

38400 bps

DMA buffering support5

Yes

No

PPP framing on chip6

Yes

No

IP fast switching7

Yes

No

5.Direct Memory Access (DMA) buffering moves data packets directly to and from system memory without interrupting the main CPU. This process removes overhead from the CPU and increases overall system performance.

5.Direct Memory Access (DMA) buffering moves data packets directly to and from system memory without interrupting the main CPU. This process removes overhead from the CPU and increases overall system performance.

6.PPP framing on a hardware chip removes overhead from the CPU on the router, which enables the router to sustain 115200 bps throughput on all asynchronous ports simultaneously.

6.PPP framing on a hardware chip removes overhead from the CPU on the router, which enables the router to sustain 115200 bps throughput on all asynchronous ports simultaneously.

7.After the destination of the first IP packet is added to the fast switching cache, it is fast switched to and from other interfaces with minimal involvement from the main processor.

7.After the destination of the first IP packet is added to the fast switching cache, it is fast switched to and from other interfaces with minimal involvement from the main processor.

command. Access servers do not have this restriction. Use the line command with the appropriate line configuration commands for modem control, such as speed.

Only IP packets can be sent across lines configured for SLIP. PPP supports transmission of IP, Internet Packet Exchange (IPX), and AppleTalk packets on an asynchronous serial interface.

See the “Line AUX Configuration Example” section for an example that shows how to configure the AUX port.

Establishing and Controlling the EXEC Process

By default, the Cisco IOS software starts an EXEC process on all lines. However, you can control EXEC processes, as follows:

- Turn the EXEC process on or off. (A serial printer, for example, should not have an EXEC session started.)

- Set the idle terminal timeout interval.

The EXEC command interpreter waits for a specified amount of time to receive user input. If no input is detected, the EXEC facility resumes the current connection. If no connections exist, it returns the terminal to the idle state and disconnects the incoming connection.

To control the EXEC process, use the following commands in line configuration mode:

Command

Purpose

Step 1

Turns on EXEC processes.

Step 2

]

Sets the idle terminal timeout interval.

See the “High-Density Dial-In Solution Using Autoselect and EXEC Control Example” section for an example of configuring control over the EXEC process.

Enabling Routing on Asynchronous Interfaces

To route IP packets on an asynchronous interface, use one of the following commands in interface configuration mode:

Command

Purpose

Configures an asynchronous interface for dynamic routing. Use this command to manually bring up PPP from an EXEC session.

Automatically configures an asynchronous interface for routing. Use this command to enable two routers to communicate over an asynchronous dial backup link.

keyword at the SLIP or PPP command line.

command, there is no way to enable the use of routing protocols automatically on a dedicated asynchronous interface.

See the following sections for examples of enabling routing on asynchronous interfaces:

- Asynchronous Interface As the Only Network Interface Example

- IGRP Configuration Example

Configuring Dedicated or Interactive PPP and SLIP Sessions

You can configure one or more asynchronous interfaces on your access server (and one on a router) to be in dedicated network interface mode. In dedicated mode, an interface is automatically configured for SLIP or PPP connections. There is no user prompt or EXEC level, and no end-user commands are required to initiate remote-node connections. If you want a line to be used only for SLIP or PPP connections, configure the line for dedicated mode.

In interactive mode, a line can be used to make any type of connection, depending on the EXEC command entered by the user. For example, depending on its configuration, the line could be used for Telnet or XRemote connections, or SLIP or PPP encapsulation. The user is prompted for an EXEC command before a connection is initiated.

You can configure an asynchronous interface to be in dedicated network mode. When the interface is configured for dedicated mode, the end user cannot change the encapsulation method, address, or other parameters.

To configure an interface for dedicated network mode or to return it to interactive mode, use one of the following commands in interface configuration mode:

Command

Purpose

Places the line into dedicated asynchronous network mode.

Returns the line to interactive mode.

By default, no asynchronous mode is configured. In this state, the line is not available for inbound networking because the SLIP and PPP connections are disabled.

See the “Dedicated Asynchronous Interface Configuration Example” section for an example of how to configure a dedicated asynchronous interface.

Conserving Network Addresses

. An unnumbered interface does not have an address. Network resources are therefore conserved because fewer network numbers are used and routing tables are smaller.

To configure an unnumbered interface, use the following command in interface configuration mode:

Command

Purpose

Conserves IP addresses by configuring the asynchronous interfaces as unnumbered, and assigns the IP address of the interface type that you want to leverage.

Whenever the unnumbered interface generates a packet (for example, a routing update), it uses the address of the specified interface as the source address of the IP packet. It also uses the address of the specified interface to determine which routing processes are sending updates over the unnumbered interface.

You can use the IP unnumbered feature even if the system on the other end of the asynchronous link does not support it. The IP unnumbered feature is transparent to the other end of the link because each system bases its routing activities on information in the routing updates it receives and on its own interface address.

See the “Network Address Conservation Using the ip unnumbered Command Example” section for an example of how to conserve network addresses.

Using Advanced Addressing Methods for Remote Devices

You can control whether addressing is dynamic (the user specifies the address at the EXEC level when making the connection) or whether default addressing is used (the address is forced by the system). If you specify dynamic addressing, the router must be in interactive mode and the user will enter the address at the EXEC level.

keyword, the default address is used.

This section describes the following optional tasks:

- Assigning a Default Asynchronous Address

- Allowing an Asynchronous Address to Be Assigned Dynamically

Assigning a Default Asynchronous Address

To assign a permanent default asynchronous address, use the following command in interface configuration mode:

Command

Purpose

Assigns a default IP address to an asynchronous interface.

EXEC command before the line is placed into asynchronous mode.

EXEC command. The transaction is validated by the TACACS server, when enabled, and the line is put into network mode using the address that is in the configuration file.

EXEC command and let the server select the address to use.

See the following sections for examples:

- Modem Asynchronous Group Example

- Configuring Specific IP Addresses for an Interface

- IP and PPP Asynchronous Interface Configuration Example

Allowing an Asynchronous Address to Be Assigned Dynamically

EXEC command and is prompted for an address or logical host name. The address is validated by TACACS, when enabled, and the line is assigned the given address and put into asynchronous mode. Assigning asynchronous addresses dynamically is useful when you want to assign set addresses to users. For example, an application on a personal computer that automatically dials in using Serial Line Internet Protocol (SLIP) and polls for electronic mail messages can be set up to dial in periodically and enter the required IP address and password.

To assign asynchronous addresses dynamically, use the following command in interface configuration mode:

Command

Purpose

Allows the IP address to be assigned when the protocol is initiated.

The dynamic addressing features of the internetwork allow packets to get to their destination and back regardless of the access server, router, or network they are sent from. For example, if a host such as a laptop computer moves from place to place, it can keep the same address no matter where it is dialing in from.

Logical host names are first converted to uppercase and then sent to the TACACS server for authentication.

See the following sections for examples of configurations that allow asynchronous addresses to be assigned dynamically:

- Access Restriction on the Asynchronous Interface Example

- Asynchronous Routing and Dynamic Addressing Configuration Example

- Network Address Conservation Using the ip unnumbered Command Example

Optimizing Available Bandwidth

Asynchronous lines have relatively low bandwidth and can easily be overloaded, resulting in slow traffic across these lines.

To optimize available bandwidth, perform either of the following optional tasks:

- Configuring Header Compression

- Forcing Header Compression at the EXEC Level

Configuring Header Compression

One way to optimize available bandwidth is by using TCP header compression. Van Jacobson TCP header compression (defined by RFC 1144) can increase bandwidth availability two- to five-fold when compared to lines not using header compression. Theoretically, it can improve bandwidth availability by a ratio of seven to one.

To configure header compression, use the following command in interface configuration mode:

Command

Purpose

]

Configures Van Jacobson TCP header compression on the asynchronous link.

Forcing Header Compression at the EXEC Level

On SLIP interfaces, you can force header compression at the EXEC prompt on a line on which header compression has been set to passive. This option allows more efficient use of the available bandwidth and does not require entering privileged configuration mode.

To implement header compression, use the following command in interface configuration mode:

Command

Purpose

Allows status of header compression to be assigned at the user level.

option.

See the following sections for examples of header compression:

- TCP Header Compression Configuration Example

- Network Address Conservation Using the ip unnumbered Command Example

- IGRP Configuration Example

Configuration Examples for Asynchronous Interfaces and Lines

This section provides the following asynchronous interface configuration examples:

- Interface and Line Configuration Examples

- Line AUX Configuration Example

- Rotary Group Examples

- Dedicated Asynchronous Interface Configuration Example

- Access Restriction on the Asynchronous Interface Example

- Group and Member Asynchronous Interface Examples

- Asynchronous Interface Address Pool Examples

- IP and SLIP Using an Asynchronous Interface Example

- IP and PPP Asynchronous Interface Configuration Example

- Asynchronous Routing and Dynamic Addressing Configuration Example

- TCP Header Compression Configuration Example

- Network Address Conservation Using the ip unnumbered Command Example

- Asynchronous Interface As the Only Network Interface Example

- Routing on a Dedicated Dial-In Router Example

- IGRP Configuration Example

Interface and Line Configuration Examples

This section contains the following examples:

- Asynchronous Interface Backup DDR Configuration Example

- Passive Header Compression and Default Address Example

- High-Density Dial-In Solution Using Autoselect and EXEC Control Example

- Asynchronous Line Backup DDR Configuration Example

Asynchronous Interface Backup DDR Configuration Example

The following is an example of one asynchronous interface configuration on a Cisco AS2511-RJ access server that is used in an asynchronous backup DDR scenario:

interface async 1

description ASYNC LINE 5293731 TO HIGHWAY

encapsulation ppp

async default routing

async mode dedicated

dialer in-band

dialer map ip 192.168.10.2 name Router2 broadcast

dialer-group 1

ppp authentication chap

Passive Header Compression and Default Address Example

The following configuration shows interface and line configuration. The interface is configured with access lists, passive header compression, and a default address. The line is configured for TACACS authentication.

interface async 1

ip access-group 1 in

ip access-group 1 out

ip tcp header-compression passive

async default ip address 172.31.176.201

line 1

login tacacs

location 457-5xxx

exec-timeout 20 0

password XXXXXXXX

session-timeout 20

stopbits 1

High-Density Dial-In Solution Using Autoselect and EXEC Control Example

The following example configures a Cisco AS5800 access server, which is used as a high-density dial-in solution:

line 1/2/00 1/9/71

session-timeout 30

exec-timeout 30 0

absolute-timeout 240

autoselect during-login

autoselect ppp

modem InOut

transport preferred none

transport input all

Asynchronous Line Backup DDR Configuration Example

The following example configures one asynchronous line on a Cisco AS2511-RJ access server that is used in an asynchronous backup DDR scenario:

line 1

modem InOut

speed 115200

transport input all

flowcontrol hardware

Line AUX Configuration Example

command to determine which asynchronous interface corresponds to the AUX port. The IP address on the AUX ports of both routers are in the same subnet

interface Async1

ip address 192.168.10.1 255.255.255.0

encapsulation ppp

async dynamic routing

async mode dedicated

!

no ip classless

ip route 0.0.0.0 0.0.0.0 Async1 /Default route points to the Async1 (AUX port) interface.

!

!

logging buffered

!

line con 0

exec-timeout 0 0

line aux 0

modem InOut

transport input all

rxspeed 38400

txspeed 38400

Rotary Group Examples

The following example establishes a rotary group consisting of virtual terminal lines 2 through 4 and defines a password on those lines. By using Telnet to connect to TCP port 3001, the user gets the next free line in the rotary group. The user need not remember the range of line numbers associated with the password.

line vty 2 4

rotary 1

password letmein

login

The following example enables asynchronous rotary line queueing:

line 1 2

rotary 1 queued

The following example enables asynchronous rotary line queueing using the round-robin algorithm:

line 1 2

rotary 1 queued round-robin

Dedicated Asynchronous Interface Configuration Example

The following example shows how to assign an IP address to an asynchronous interface and place the line in dedicated network mode. Setting the stop bit to 1 is a performance enhancement.

line 20

location Department PC Lab

stopbits 1

speed 19200

!

interface async 20

async default ip address 172.18.7.51

async mode dedicated

Access Restriction on the Asynchronous Interface Example

The following example shows how to allow most terminal users access to anything on the local network, but restrict access to certain servers designated as asynchronous servers:

! access list for normal connections

access-list 1 permit 192.168.0.0 0.0.255.255

!

access-list 2 permit 192.168.42.55

access-list 2 permit 192.168.111.1

access-list 2 permit 192.168.55.99

!

line 1

speed 19200

flow hardware

modem inout

interface async 1

async mode interactive

async dynamic address

ip access-group 1 out

ip access-group 2 in

Group and Member Asynchronous Interface Examples

The following examples are included in this section:

- Asynchronous Group Interface Examples

- Modem Asynchronous Group Example

- High-Density Dial-In Solution Using an Asynchronous Group

Asynchronous Group Interface Examples

The following example shows how to create an asynchronous group interface 0 with group interface members 2 through 7, beginning in global configuration mode:

interface group-async 0

group-range 2 7

The following example shows how you need to configure asynchronous interfaces 1, 2, and 3 separately if you do not have a group interface configured:

interface Async1

ip unnumbered Ethernet0

encapsulation ppp

async default ip address 172.30.1.1

async mode interactive

async dynamic routing

!

interface Async2

ip unnumbered Ethernet0

encapsulation ppp

async default ip address 172.30.1.2

async mode interactive

async dynamic routing

!

interface Async3

ip unnumbered Ethernet0

!

encapsulation ppp

async default ip address 172.30.1.3

async mode interactive

async dynamic routing

The following example configures the same interfaces, but from a single group asynchronous interface:

interface Group-Async 0

ip unnumbered Ethernet0

encapsulation ppp

async mode interactive

async dynamic routing

group-range 1 3

member 1 async default ip address 172.30.1.1

member 2 async default ip address 172.30.1.2

member 3 async default ip address 172.30.1.3

Modem Asynchronous Group Example

To configure a group asynchronous interface, specify the group async number (an arbitrary number) and the group range (beginning and ending asynchronous interface number).

The following example shows the process of creating and configuring a group asynchronous interface for asynchronous interfaces 1 through 96 on a Cisco AS5300 access server, which is loaded with ninety-six 56K MICA technologies modems:

interface group-async 1

ip unnumbered ethernet 0

encapsulation ppp

async mode interactive

ppp authentication chap pap

peer default ip address pool default

group-range 1 96

High-Density Dial-In Solution Using an Asynchronous Group

The following example configures a Cisco AS5800 access server that is used as a high-density dial-in solution:

interface group-async 0

ip unnumbered FastEthernet0/2/0

encapsulation ppp

async mode interactive

peer default ip address pool default

no cdp enable

ppp authentication chap

hold-queue 10 in

group-range 1/2/00 1/9/71

Asynchronous Interface Address Pool Examples

The following sections provide examples of the use of Dynamic Host Configuration Protocol (DHCP) and local pooling mechanisms:

- DHCP Pooling Example

- Local Pooling Example

- Configuring Specific IP Addresses for an Interface

DHCP Pooling Example

The following global configuration example enables DHCP proxy-client status on all asynchronous interfaces on the access server:

ip address-pool dhcp-proxy-client

The following global configuration example shows how to specify which DHCP servers are used on your network. You can specify up to four servers using IP addresses or names. If you do not specify servers, the default is to use the IP limited broadcast address of 255.255.255.255 for transactions with any and all discovered DHCP servers.

ip dhcp-server jones smith wesson

The following interface configuration example illustrates how to disable DHCP proxy-client functionality on asynchronous interface 1:

async interface

interface 1

no peer default ip address

Local Pooling Example

The following example shows how to select the IP pooling mechanism and how to create a pool of local IP addresses that are used when a client dials in on an asynchronous line. The default address pool comprises IP addresses 172.30.0.1 through 172.30.0.28.

! This command tells the access server to use a local pool.

ip address-pool local

! This command defines the ip address pool.

! The address pool is named group1 and comprised of addresses.

! 172.30.0.1 through 172.30.0.28 inclusive

ip local-pool group1 172.30.0.1 172.30.0.28

Configuring Specific IP Addresses for an Interface

The following example shows how to configure the access server so that it will use the default address pool on all interfaces except interface 7, on which it will use an address pool called lass:

ip address-pool local

ip local-pool lass 172.30.0.1

async interface

interface 7

peer default ip address lass

IP and SLIP Using an Asynchronous Interface Example

The following example configures IP and SLIP on asynchronous interface 6. The IP address for the interface is assigned to Ethernet 0, interactive mode has been enabled, and the IP address of the client PC running SLIP has been specified.

IP and the appropriate IP routing protocols have already been enabled on the access server or router.

interface async 6

ip unnumbered ethernet 0

encapsulation slip

async mode interactive

async default ip address 172.18.1.128

IP and PPP Asynchronous Interface Configuration Example

The following example configures IP and PPP on asynchronous interface 6. The IP address for the interface is assigned to Ethernet 0, interactive mode has been enabled, and the IP address of the client PC running PPP has been specified. IP and the appropriate IP routing protocols have already been enabled on the access server or router.

interface async 6

ip unnumbered ethernet 0

encapsulation ppp

async mode interactive

peer default ip address 172.18.1.128

Asynchronous Routing and Dynamic Addressing Configuration Example

The following example shows a simple configuration that allows routing and dynamic addressing.

command, routing protocols will be sent and received.

interface async 6

async dynamic routing

async dynamic address

TCP Header Compression Configuration Example

connection command entered by the user or if the connecting system sends compressed packets.

interface async 7

ip address 172.31.79.1

async default ip address 172.31.79.2

ip tcp header-compression passive

Network Address Conservation Using the ip unnumbered Command Example

The following example shows how to configure your router for routing using unnumbered interfaces. The source (local) address is shared between the Ethernet 0 and asynchronous 6 interfaces (172.18.1.1). The default remote address is 172.18.1.2.

interface ethernet 0

ip address 172.18.1.1 255.255.255.0

!

interface async 6

ip unnumbered ethernet 0

async dynamic routing

! Default address is on the local subnet.

async dynamic address

async default ip address 172.18.1.2

ip tcp header-compression passive

The following example shows how the IP unnumbered configuration works. Although the user is assigned an address, the system response shows the interface as unnumbered, and the address entered by the user will be used only in response to BOOTP requests.

Router> slip /compressed 10.11.11.254

Password:

Entering async mode.

Interface IP address is unnumbered, MTU is 1500 bytes.

Header compression is On.

Asynchronous Interface As the Only Network Interface Example

The following example shows how one of the asynchronous lines can be used as the only network interface. The router is used primarily as a terminal server, but is at a remote location and dials in to the central site for its only network connection.

ip default-gateway 10.11.12.2

interface ethernet 0

shutdown

interface async 1

async dynamic routing

ip tcp header-compression on

async default ip address 10.11.16.12

async mode dedicated

ip address 10.11.12.32 255.255.255.0

Routing on a Dedicated Dial-In Router Example

The following example shows how a router is set up as a dedicated dial-in router. Interfaces are configured as IP unnumbered to conserve network resources, primarily IP addresses.

ip routing

interface ethernet 0

ip address 10.129.128.2 255.255.255.0

!

interface async 1

ip unnumbered ethernet 0

async dynamic routing

! The addresses assigned with SLIP or PPP EXEC commands are not used except

! to reply to BOOTP requests.

! Normally, the routers dialing in will have their own address and not use BOOTP at all.

async default ip address 10.11.11.254

!

interface async 2

ip unnumbered ethernet 0

async default ip address 10.11.12.16

ip tcp header-compression passive

async mode dedicated

!

! Run RIP on the asynchronous lines because few implementations of SLIP

! understand IGRP. Run IGRP on the Ethernet (and in the local network).

!

router igrp 110

network 10.11.12.0

! Send routes from the asynchronous lines on the production network.

redistribute RIP

! Do not send IGRP updates on the asynchronous interfaces.

passive-interface async 1

!

router RIP

network 10.11.12.0

redistribute igrp

passive-interface ethernet 0

! Consider filtering everything except a default route from the routing

! updates sent on the (slow) asynchronous lines.

distribute-list 1 out

ip unnumbered async 2

async dynamic routing

IGRP Configuration Example

In the following example, only the Interior Gateway Routing Protocol (IGRP) TCP/IP routing protocol is running; it is assumed that the systems that are dialing in to use routing will either support IGRP or have some other method (for example, a static default route) of determining that the router is the best place to send most of its packets.

router igrp 111

network 10.11.12.0

interface ethernet 0

ip address 10.11.12.92 255.255.255.0

!

interface async 1

async default ip address 10.11.12.96

async dynamic routing

ip tcp header-compression passive

ip unnumbered ethernet 0

line 1

modem ri-is-cd

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2001-2009 Cisco Systems, Inc. All rights reserved.

Asynchronous Call Queueing by Role

First Published: June 06, 2004

Last Updated: June 30, 2009

The Asynchronous Call Queueing by Role feature allows priority users making Telnet connection requests to busy asynchronous rotary groups to be placed at the head of the queue when asynchronous rotary line queueing is enabled. When a priority user makes a Telnet connection request, that user goes to the head of the queue, and a second requester will be placed behind the first. This feature allows a priority user to access the first available line.

The Asynchronous Call Queuing by role feature allows priority users to bypass the queue and access the first available line to complete necessary administrative tasks more quickly.

Note Priority users must have the privilege level of administrator (PRIV_ROOT) to take advantage of the Asynchronous Call Queueing by Role feature.

Finding Feature Information

For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the “Feature Information for Asynchronous Call Queueing by Role” section.

. An account on Cisco.com is not required.

Contents

- Prerequisites for Asynchronous Call Queueing by Role

- Restrictions for Asynchronous Call Queueing by Role

- Information About Asynchronous Call Queueing by Role

- How to Configure Asynchronous Call Queueing by Role

- Configuration Examples for Asynchronous Call Queueing by Role

- Additional References

- Glossary

Prerequisites for Asynchronous Call Queueing by Role

The router must have operational and successfully configured asynchronous interfaces, and asynchronous rotary groups must be enabled.

Restrictions for Asynchronous Call Queueing by Role

To configure the Asynchronous Call Queueing by Role feature, you must also configure asynchronous rotary line queueing. Make sure you comply with the following requirements when configuring asynchronous rotary line queueing:

- You must configure more virtual terminal lines than will ever be used by waiting asynchronous rotary connection attempts. Even when the queue is at its maximum, there must be at least one virtual terminal line available so that system operators or network administrators can use Telnet to access the router to show, debug, or configure system performance.

- When adding lines to a rotary group, all lines must be either queued or not queued. A mixture of queued and nonqueued lines in the same rotary group is not supported and can result in unexpected behavior.

- All lines within a queued rotary group need to use the same authentication method. Using different authentication methods within the same rotary group can result in unexpected behavior.

.

Information About Asynchronous Call Queueing by Role

To configure asynchronous rotary linequeueing and the Asynchronous Call Queueing by Role feature, you must understand the following concepts:

- Authentication of Connections

Authentication of Connections

Connections are authenticated using the method specified for the line configurations for the asynchronous rotary group. If a connection is queued, authentication is done prior toqueueing, and no authentication is done when the connection is later established.

How to Configure Asynchronous Call Queueing by Role

This section contains the following procedures:

- Configuring Asynchronous Call Queueing by Role (required)

- Monitoring and Maintaining Asynchronous Rotary Line Queues (optional)

Configuring Asynchronous Call Queueing by Role

This task configures asynchronous rotary line queueing and the Asynchronous Call queueing by Role feature.

SUMMARY STEPS

]

]]

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

]

Router(config)# line 1 2

Identifies a specific line or group of lines for configuration and enters line configuration mode.

Step 4

]]

Router(config-line)# rotary 1 queued by-role

Enables asynchronous rotary line queueing on the designated line or group of lines.

- The optional by-role keyword enables asynchronous call queueing by role.

Troubleshooting Tips

commands in privileged EXEC mode to determine the source of the problem:

- debug async async-queue

- debug ip tcp transactions

- debug modem

commands.

Monitoring and Maintaining Asynchronous Rotary Line Queues

This task displays queued lines and removes lines from the queue:

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router# show line async-queue 1

Displays which lines are queued.

Step 4

clear line async-queue rotary-group

Router# clear line async-queue 1

Clears all rotary queues or the specified rotary queue.

- If the rotary-group argument is not specified, all rotary queues are removed.

Configuration Examples for Asynchronous Call Queueing by Role

This section provides the following configuration examples:

- Configuring Asynchronous Call Queueing by Role: Example

- Verifying Asynchronous Call Queueing by Role: Example

Configuring Asynchronous Call Queueing by Role: Example

The following example enables asynchronous rotary line queueing and by-role queueing on lines 1 and 2 on rotary group 1:

line 1 2

rotary 1 queued by-role

Verifying Asynchronous Call Queueing by Role: Example

command when by-role queueing is enabled on lines tty35 and tty38:

Router# show line async-queue

Showing async-queue for ALL rotary groups

Queue for Rotary Group 1:

Pos Waiting TTY Dest Port Source Host Waiting Time

1 tty66 3001 10.2.72.13 00:01:32

2 tty67 3001 10.2.72.13 00:01:23

Lines which have Queueing enabled [tty (group)]:

tty33 (2) tty34 (2)

Lines which have Queueing by role enabled [tty (group)]:

tty35 (1) tty38 (1)

Additional References

The following sections provide additional references related to the Asynchronous Call Queueing by Role feature.

Related Documents

Related Topic

Document Title

Configuring asynchronous lines and rotary groups

feature guide

DIAL commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS commands

commands

Standards

Standards

Title

None

—

MIBs

MIBs

MIBs Link

None

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

RFCs

RFCs

Title

None

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

Feature Information for Asynchronous Call Queueing by Role

lists the features in this module and provides links to specific configuration information.

Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.

. An account on Cisco.com is not required.

Note Table 1 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.

Table 1 Feature Information for Asynchronous Call Queueing by Role

Feature Name

Releases

Feature Information

Asynchronous Call Queueing by Role

12.1(3)T

This feature allows Telnet connection requests to busy asynchronous rotary groups to be queued so that users automatically obtain the next available line, rather than needing to try repeatedly to open a Telnet connection. The Cisco IOS software sends a periodic message to the user to update progress in the connection queue.

Glossary

—Term describing digital signals that are sent without precise clocking. Such signals generally have different frequencies and phase relationships. Asynchronous transmissions usually encapsulate individual characters in control bits (called start and stop bits) that designate the beginning and end of each character.

—Several contiguous lines that allow a connection to be made to the next free line in the group. Also called a hunt group.

—Transmission Control Protocol. Connection-oriented transport layer protocol that provides reliable full-duplex data transmission. TCP is part of the TCP/IP protocol stack.

—Standard terminal emulation protocol in the TCP/IP protocol stack. Telnet is used for remote terminal connection, enabling users to log in to remote systems and use resources as if they were connected to a local system. Telnet is defined in RFC 854.

—See TCP.

—terminal line.

—virtual terminal line.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2004–2009 Cisco Systems, Inc. All rights reserved.

Configuring Asynchronous Serial Traffic

over UDP

This chapter describes how to communicate with a modem using the Asynchronous Serial Traffic over UDP feature in the following main sections:

- UDPTN Overview

- Asynchronous Serial Traffic over UDP Configuration Task List

See the “UDPTN Configuration Examples” section for configuration examples.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

, Release 12.2. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

UDPTN Overview

The Asynchronous Serial Traffic over UDP feature provides the ability to encapsulate asynchronous data into User Datagram Protocol (UDP) packets and then unreliably send this data without needing to establish a connection with a receiving device. This process is referred to as UDP Telnet (UDPTN), although it does not—and cannot—use the Telnet protocol. UDPTN is similar to Telnet in that both are used to send data, but UDPTN is unique in that it does not require that a connection be established with a receiving device. You load the data that you want to send through an asynchronous port, and then send it, optionally, as a multicast or a broadcast. The receiving device(s) can then receive the data whenever it wants. If the receiver ends reception, the transmission is unaffected.

The Asynchronous Serial Traffic over UDP feature provides a low-bandwidth, low-maintenance method to unreliably deliver data. This delivery is similar to a radio broadcast: It does not require that you establish a connection to a destination; rather, it sends the data to whatever device wants to receive it. The receivers are free to begin or end their reception without interrupting the transmission.

It is a low-bandwidth solution for delivering streaming information for which lost packets are not critical. Such applications include stock quotes, news wires, console monitoring, and multiuser chat features.

This feature is particularly useful for broadcast, multicast, and unstable point-to-point connections. This feature may not work as expected when there are multiple users on the same port number in a nonmulticast environment. The same port must be used for both receiving and sending.

Asynchronous Serial Traffic over UDP Configuration Task List

To configure the Asynchronous Serial Traffic over UDP feature, perform the tasks described in the following sections:

- Preparing to Configure Asynchronous Serial Traffic over UDP (Required)

- Configuring a Line for UDPTN (Required)

- Enabling UDPTN (Required)

- Verifying UDPTN Traffic (Optional but Recommended)

See the “UDPTN Configuration Examples” section at the end of this chapter for multicast, broadcast, and point-to-point UDPTN configuration examples.

Preparing to Configure Asynchronous Serial Traffic over UDP

for information on how to configure broadcast flooding.

Configuring a Line for UDPTN

To configure the line that will be used to send or receive UDP packets, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Enters line configuration mode for the line number specified.

Step 2

Enables the line to transport UDP packets.

Step 3

Sends packets every 1000 milliseconds.

Step 4

Sends packets after every new line.

Step 5

Disables timeout connection closing.

Enabling UDPTN

There are two methods of enabling UDPTN. You can manually enable UDPTN when you want to begin transmission or reception, or you can configure the router to automatically enable UDPTN when a connection is made to the line.

To manually enable UDPTN and begin UDPTN transmission or reception, use the following command in EXEC mode:

Command

Purpose

]

keyword if the router will only be sending or receiving UDPTN.

To automatically enable UDPTN when a connection is made to the line, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Enters line configuration mode for the line number specified.

Step 2

]

keyword if the router will only be sending or receiving UDPTN.

Verifying UDPTN Traffic

To verify that UDPTN is enabled correctly, perform the following steps:

command.

EXEC command, and then observe the debug output.

The following debug output shows a UDPTN session being successfully established and then disconnected.

Router# debug udptn

Router# udptn 172.16.1.1

Trying 172.16.1.1 ... Open

*Mar 1 00:10:15.191:udptn0:adding multicast group.

*Mar 1 00:10:15.195:udptn0:open to 172.16.1.1:57 Loopback0jjaassdd

*Mar 1 00:10:18.083:udptn0:output packet w 1 bytes

*Mar 1 00:10:18.087:udptn0:Input packet w 1 bytes

Router# disconnect

Closing connection to 172.16.1.1 [confirm] y

Router#

command to verify that the socket being used for UDPTN opened correctly.

Router# show ip socket

Proto Remote Port Local Port In Out Stat TTY OutputIF

17 --listen-- 172.21.14.90 67 0 0 89 0

17 0.0.0.0 520 172.21.14.90 520 0 0 1 0

17 1.1.1.2 57 1.1.1.1 57 0 0 48 0

17 224.1.1.1 57 1.2.2.2 57 0 0 48 0 Loopback0

UDPTN Configuration Examples

This section provides the following UDPTN configuration examples:

- Multicast UDPTN Example

- Broadcast UDPTN Example

- Point-to-Point UDPTN Example

Multicast UDPTN Example

These configurations are for multicast UDPTN. The router that is multicasting does not require a multicast configuration—it simply sends to the multicast IP address.

Router That Is Multicasting

ip multicast-routing

interface ethernet 0

ip address 10.1.1.1 255.255.255.0

ip pim dense-mode

!

line 5

no session-timeout

transport output udptn

dispatch-timeout 10000

dispatch-character 13

modem in

autocommand udptn 172.1.1.1 /transmit

Receiving Routers

ip multicast-routing

interface ethernet 0

ip address 10.99.98.97 255.255.255.192

ip pim dense-mode

!

line 0 16

transport output udptn telnet lat rlogin

autocommand udptn 172.1.1.1 /receive

Broadcast UDPTN Example

command.

Router That Is Broadcasting

interface ethernet 0

ip address 10.1.1.1 255.255.255.0

!

line 5

no session-timeout

transport output udptn

dispatch-timeout 10000

dispatch-character 13

modem in

autocommand udptn 255.255.255.255 /transmit

Receiving Routers

interface ethernet 0

ip address 10.99.98.97 255.255.255.192

!

line 0 16

transport output udptn telnet lat rlogin

autocommand udptn 255.255.255.255 /receive

Point-to-Point UDPTN Example

command.

Router A

interface ethernet 0

ip address 10.54.46.1 255.255.255.192

!

line 5

no session-timeout

transport output udptn

dispatch-timeout 10000

dispatch-character 13

modem in

autocommand udptn 10.54.46.2

Router B

interface ethernet 0

ip address 10.54.46.2 255.255.255.192

!

line 10

no session-timeout

transport output udptn

dispatch-timeout 10000

dispatch-character 13

modem in

autocommand udptn 10.54.46.1

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2001-2008 Cisco Systems, Inc. All rights reserved.

Configuring and Managing Integrated Modems

The Cisco IOS software provides commands that manage modems that reside inside access servers or routers in the form of modem cards. This chapter describes the modem management tasks. It includes the following main sections:

- Modems and Modem Feature Support

- Managing Modems

- Configuration Examples for Modem Management

For additional instructions for configuring Cisco access servers, see the chapter “Configuring and Managing Cisco Access Servers and Dial Shelves” in this publication.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

Modems and Modem Feature Support

The Cisco IOS software supports three types of integrated modems for Cisco access servers and access routers:

- Modem ISDN channel aggregation (MICA) digital modem

- NextPort digital modem

- NM-AM network module analog modem

lists device support for each of the Cisco access server hardware platforms.

Table 1 Cisco IOS Modems and Modem Feature Support

Device Support

Cisco AS5300

Cisco AS5350

Cisco AS5400

Cisco AS5800

Cisco 2600/3600 Series Routers

Integrated modems

6- and 12-port MICA

60-port NextPort CSM v6DFC

108-port NextPort CSM v6DFC

72- and 144-port MICA

324-port NextPort CSM v6DFC

6-port, 12-port, 18-port, 24-port, or 30-port MICA NM-DM

8- and 16-port analog NM-AM

V.90

Yes

Yes

Yes

Yes

Yes with NM-DM

V.110

Yes

Yes

Yes

Yes

Yes with NM-DM

V.120

No, CPU only

Yes

Yes

Yes with 324-port NextPort1 CSM v6DFC

No, CPU only

1.For more detailed information regarding the V.120 functionalities that are supported both by NextPort and Cisco IOS software, see the section “V.120 Bit Rate Adaptation Standard.”

1.For more detailed information regarding the V.120 functionalities that are supported both by NextPort and Cisco IOS software, see the section “V.120 Bit Rate Adaptation Standard.”

Note If the platform is using MICA technologies modems, the V.120 rate adaptation is done by CPU on vty lines like protocol translation sessions.

Note Typically, parity and databits commands have no effect on modem lines without UART. However, since modem lines such as WIC-1AM and WIC-2AM are implemented though UART and use an internal UART, the parity and databits commands can be used to set async parity framing. The following commands may be used on WIC-AM modem cards although changing the DTE speed and stopbits on these lines have no effect: parity, databits, stopbits, flowcontrol, speed, rxspeed, and txspeed.

for a summary and comparison of the Cisco IOS commands used for the MICA and NextPort modems.

V.90 Modem Standard

Study Group 16 of the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) developed the V.90 modem standard for multimedia systems. The V.90 standard describes a digital modem and analog modem pair for use on the public switched telephone network (PSTN). V.90 modems are designed for connections that are digital at one end and have only one digital-to-analog conversion. The V.90 standard is expected to be widely used for applications such as Internet and online service access. Download speeds of up to 56,000 bits per second (bps) are possible, depending on telephone line conditions, with upload speeds of up to 33,600 bps.

V.110 Bit Rate Adaption Standard

V.110 is a bit rate adaptation standard defined by the ITU that provides a standard method of encapsulating data over global system for mobile telecommunication (GSM) and ISDN networks. V.110 allows for reliable transport of asynchronous or synchronous data. V.110 adapts a low-speed connection to an ISDN B channel allowing the remote station or terminal adapter to use the fast call setup times offered by ISDN. This feature allows V.110 calls to be originated and terminated over ISDN. It also enables GSM wireless connectivity.

V.110, as an alternative to V.120, provides DTE with V-series type interfaces with access to ISDN network by bit stuffing. Many V.110 devices are used in Europe and Japan. In Japan, MICA supports the Personal-Handyphone-System Internet Access Forum Standard (PIAFS) protocol, which is similar to V.110.

The V.110 implementation for calls on MICA modems is managed by special boardware and modem code, along with the appropriate Cisco IOS image, in a manner similar to other modulation standards. This MICA V.110 implementation provides V.110 user rates ranging from 600 bps to 38,400 bps.

V.110 is supported on the following Cisco devices and network modules:

- Cisco AS5300-series access servers

- Cisco 3620, 3640, and 3660 access routers

- NM-6DM, NM-12DM, NM-18DM, NM-24DM, and NM-30DM network modules

The digital signal processors (DSPs) on the board can function as either modems or V.110 terminal adapters (or V.120 terminal adapters for NextPort DSPs). Based on the ISDN Q.931 bearer capability information element, the Cisco IOS software configures the DSP to treat the incoming call as a modem call, a V.110 call, or a V.120 call.

Figure 1 shows a dial-in scenario for how V.110 technology can be used with a stack of Cisco AS5300-series access servers.

Figure 1 V.110 Dial-In Scenario Using a Stack of Cisco AS5300-Series Access Servers

V.120 Bit Rate Adaptation Standard

ITU-T Recommendation V.120 revised by the ITU-T Study Group 14. V.120 describes a standard that can be used for adapting terminals with non-ISDN standard network interfaces to an ISDN. It is intended to be used between two terminal adapter (TA) functional groups, between two ISDN terminal (TE1) functional groups, between a TA and a TE1, or between either a TA or TE1 and an interworking facility inside a public or private ISDN.

V.120 allows for reliable transport of synchronous, asynchronous, or bit transparent data over ISDN bearer channels. Cisco provides three V.120 support features for terminal adapters that do not send the low-layer compatibility fields or bearer capability V.120 information:

- Answer all incoming calls as V.120—Static configuration used when all remote users have asynchronous terminals and need to connect with a vty on the router.

- Automatically detect V.120 encapsulation—Encapsulation dynamically detected and set.

- Enable V.120 support for asynchronous access over ISDN.

For terminal adapters that send the low-layer compatibility or bearer capability V.120 information, mixed V.120 and ISDN calls are supported. No special configuration is required.

V.120 is a digital rate adaptation and cannot be done on NM-AM network module analog modems. MICA DSP firmware does not have the code to terminate V.120 calls.

NextPort supports only a subset of V.120 functionalities that are supported by Cisco IOS software. Therefore, certain V.120 calls still will need to be terminated on the CPU, even if the chassis has available NextPort modems.

Managing Modems

To manage modems, perform the tasks in the following sections; the tasks you need to perform depend upon the type and needs of your system:

- Managing SPE Firmware

- Configuring Modems in Cisco Access Servers

- Configuring Cisco Integrated Modems Using Modem Attention Commands

- Configuring Modem Pooling

- Configuring Physical Partitioning

- Configuring Virtual Partitioning

- Configuring Call Tracker

- Configuring Polling of Link Statistics on MICA Modems

- Configuring MICA In-Band Framing Mode Control Messages

- Enabling Modem Polling

- Setting Modem Poll Intervals

- Setting Modem Poll Retry

- Collecting Modem Statistics

- Troubleshooting Using a Back-to-Back Modem Test Procedure

- Clearing a Direct Connect Session on a Microcom Modem

- Displaying Local Disconnect Reasons

- Removing Inoperable Modems

- Busying Out a Modem Card

- Monitoring Resources on Cisco High-End Access Servers

Managing SPE Firmware

command.

command; otherwise, at the next reboot downloading of the specified firmware will not occur.

To upgrade SPE firmware, use the following commands:

Command

Purpose

Step 1

Enters global configuration mode.

Step 2

AS5400:

or

AS5800:

or

Enters SPE configuration mode. You can choose to configure a range of SPEs by specifying the first and last SPE in the range.

Step 3

}

Specifies the upgrade method.

keyword requests the access server to upgrade firmware at the next reboot.

Step 4

Specifies the SPE firmware file in flash memory to use for the selected SPEs. Allows you to upgrade firmware for SPEs after the new SPE firmware image is copied to your flash memory.

EXEC command to display legal IFSs. Examples of legal IFS specifications include:

- bootflash: —Loads the firmware from a separate flash memory device.

- flash: —Loads the firmware from the flash NVRAM located within the router.

- system:/ —Loads the firmware from a built-in file within the Cisco IOS image. The optional forward slash (/) and system path must be entered with this specification.

- filename —The name of the desired firmware file (for example, mica-modem-pw.2.7.3.0.bin). If the system keyword is specified, enter the path to the filename you want to download.

Step 5

Exits SPE configuration mode.

Step 6

Exits global configuration mode.

Step 7

Saves your changes.

Note As soon as a firmware file is specified, the downloading begins. Do not specify all modems and then go into an upgrade process on a busy router. The modems that are not busy will all be marked busy and the server will wait until all the modems on each of the given cards are free before upgrading the multiple-port cards. The only way to clear this situation is to start disconnecting users with a clear command. Normally, groups of modems are specified in scripts with the spe slot/spe_begin and slot/spe_end statements, and upgrades are done in a rolling fashion.

commands to verify that the modems are running the portware version you specified.

EXEC command:

Router# configure terminal

Router(config)# spe 7/0 7/17

Router(config-spe)# firmware upgrade busyout

Router(config-spe)# firmware location flash:np_6_75

Started downloading firmware flash:np_6_75.spe

Router(config-spe)# exit

Router(config)# exit

Router# show spe 7

.

.

.

SPE SPE SPE SPE Port Call

SPE# Port # State Busyout Shut Crash State Type

7/00 0000-0005 ACTIVE 1 0 0 BBBBBB ______

7/01 0006-0011 DOWNLOAD 1 0 0 bbbbbb ______

7/02 0012-0017 DOWNLOAD 1 0 0 bbbbbb ______

7/03 0018-0023 DOWNLOAD 1 0 0 bbbbbb ______

.

.

.

.

Configuring Modems in Cisco Access Servers

To configure modem support for access servers such as the Cisco AS5300 and AS5800, perform the following tasks. The list describes which tasks are required and which are optional but recommended.

- Configuring Modem Lines (Required)

- Verifying the Dial-In Connection (Optional but Recommended)

- Troubleshooting the Dial-In Connection (Optional but Recommended)

- Configuring the Modem Using a Modemcap (Required)

- Configuring the Modem Circuit Interface (Required for Digital Modems)

Configuring Modem Lines

You must configure the modem lines and set the country code to enable asynchronous connections into your access server. To configure the modems and line, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

MICA modems

NextPort SPE modems

Microcom modems

Depending on the type of modems loaded in your access server, specifies the modem vendor and country code.2 This step is only for the MICA, NextPort SPE, and Microcom modems in the Cisco AS5000 series access servers.

provide a summary and comparison of the Cisco IOS commands used for the MICA and NextPort modems.

Step 2

EXEC command to see which lines are available.

Step 3

}

option.

Step 4

}

commands with the appropriate keyword.

Step 5

Configures the lines to display the username and password prompt as soon as the line is connected, rather than waiting until the user presses the Enter or Return key at the terminal.

Step 6

or

Enables authentication across all asynchronous modem logins.

command when authentication, authorization, and accounting (AAA) authentication has been enabled.

commands to configure non-AAA user authentication.

Step 7

Configures the modem for only incoming calls.

Step 8

Returns to global configuration mode.

2.For a comprehensive list of modem country codes, see the modem country mica command and the modem country microcom_hdms command in the Cisco IOS Dial Technologies Command Reference.

2.For a comprehensive list of modem country codes, see the modem country mica command and the modem country microcom_hdms command in the Cisco IOS Dial Technologies Command Reference.

Verifying the Dial-In Connection

Before configuring any additional protocols for the line such as SLIP, PPP, or ARA, test whether the dial-in connection for the access server and modem are configured correctly for dial-in access,

Note The same configuration issues exist between the client DTE and client modem. Make sure that you have the correct EIA/TIA-232 cabling and modem initialization string for your client modem.

The following is an example of a successful connection from a PC using a known good modem to dial in to a Cisco access server:

at

OK

atdt9,5550101

CONNECT 14400/ARQ/V32/LAPM/V42BIS

User Access Verification

Username: user1

Password:

Router>

Troubleshooting the Dial-In Connection

Depending upon the problems you experience, take the appropriate action:

- If you are having problems making or receiving calls, make sure that you turned on the protocols for connecting to the lines and configured for incoming and outgoing calls.

- If the calls are not coming up at all, turn on modem debugging. Use the the modem debugging commands as follows:

command enables debugging on the modem line.

command enables debugging for lines configured for digital modems.

command enables debugging for lines configured for the ISDN and Signaling System 7 (SS7) Q.931 protocols.

co–and enables debugging for lines configured for channel-associated signaling (CAS).

Following is a sample of how to enable and then disable Cisco IOS modem debugging commands on a network access server:

Router# debug modem

Router# debug modem csm

Router# debug isdn q931

Router# no debug modem

Router# no debug modem csm

Router# no debug isdn q931

- Enter the debug modem ? command for a list of additional modem debugging commands:

Router# debug modem ?

b2b Modem Special B2B

csm CSM activity

maintenance Modem maintenance activity

mica MICA Async driver debugging

oob Modem out of band activity

tdm B2B Modem/PRI TDM

trace Call Trace Upload

- Turn off the messages by entering the no debug modem command.

Configuring the Modem Using a Modemcap

(modemcap). The Cisco IOS software contains defined modemcaps that have been found to properly initialize internal modems. Following are the names of some modemcaps available in the Cisco IOS software:

- cisco_v110—Cisco (NEC) internal V.110 TA (AS5200)

- mica—Cisco MICA HMM/DMM internal digital modem

- nextport—Cisco NextPort CSMV/6 internal digital modem

- microcom_hdms—Microcom HDMS chassis

- microcom_mimic—Cisco (Microcom) internal analog modem (NM-AM–2600/3600)

- microcom_server—Cisco (Microcom) V.34/56K internal digital modem (AS5200)

command.

command to configure it, as described in the procedure “.”Using the Modem Autoconfigure Discovery Feature

Note When configuring an internal modem, avoid using the Modem Autoconfigure Discovery feature because the feature can misdetect the internal modem type and cause the modem to start working in an unpredictable and unreproducable manner.

Using the Modem Autoconfigure Type Modemcap Feature

If you know what modem initialization string you need to use with your modem, you can create your own modemcap by performing the following steps.

command to define your own modemcap entry.

The following example defines modemcap MODEMCAPNAME:

Router(config)# modemcap edit MODEMCAPNAME miscellaneous &FS0=1&D3

Step 2 Apply the modemcap to the modem lines as shown in the following example:

Router# terminal monitor

Router# debug confmodem

Modem Configuration Database debugging is on

Router#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)#line 33 34

Router(config-line)#modem autoconfigure type MODEMCAPNAME

Jan 16 18:12:59.643: TTY34: detection speed (115200) response ---OK---

Jan 16 18:12:59.643: TTY34: Modem command: --AT&FS0=1&D3--

Jan 16 18:12:59.659: TTY33: detection speed (115200) response ---OK---

Jan 16 18:12:59.659: TTY33: Modem command: --AT&FS0=1&D3--

Jan 16 18:13:00.227: TTY34: Modem configuration succeeded

Jan 16 18:13:00.227: TTY34: Detected modem speed 115200

Jan 16 18:13:00.227: TTY34: Done with modem configuration

Jan 16 18:13:00.259: TTY33: Modem configuration succeeded

Jan 16 18:13:00.259: TTY33: Detected modem speed 115200

Jan 16 18:13:00.259: TTY33: Done with modem configuration

Note The report that is generated by the debug confmodem command can be misleading for the MICA and NextPort internal modems because these modems do not have Universal Asynchronous Receiver/Transmitter (UART) and exchange data with the CPU at speeds of hundreds of kbps.

Using the Modem Autoconfigure Discovery Feature

command.

The following example shows how to configure modem autoconfigure discovery mode:

Router# terminal monitor

Router# debug confmodem

Modem Configuration Database debugging is on

Router# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)# line 33 34

Router(config-line)# modem autoconfigure discovery

Jan 16 18:16:17.724: TTY33: detection speed (115200) response ---OK---

Jan 16 18:16:17.724: TTY33: Modem type is default

Jan 16 18:16:17.724: TTY33: Modem command: --AT&F&C1&D2S0=1H0--

Jan 16 18:16:17.728: TTY34: detection speed (115200) response ---OK---

Jan 16 18:16:17.728: TTY34: Modem type is default

Jan 16 18:16:17.728: TTY34: Modem command: --AT&F&C1&D2S0=1H0--

Jan 16 18:16:18.324: TTY33: Modem configuration succeeded

Jan 16 18:16:18.324: TTY33: Detected modem speed 115200

Jan 16 18:16:18.324: TTY33: Done with modem configuration

Jan 16 18:16:18.324: TTY34: Modem configuration succeeded

Jan 16 18:16:18.324: TTY34: Detected modem speed 115200

Jan 16 18:16:18.324: TTY34: Done with modem configuration

Configuring the Modem Circuit Interface

The next task to complete before using the integrated modem is to configure the modem circuit interface. The basic steps are outlined next:

- If the integrated modem is an analog modem, no further configuration is required; modem characteristics are set on the line.

- If the integrated modem is a digital modem, you can configure either the ISDN or CAS, as appropriate.

– For ISDN BRI and PRI, you need to select the switch type and whether ISDN accepts incoming voice or data calls. If you configure a PRI, you will need to configure the T1 or E1 controller.

– Configuring CAS is described in the chapter “Configuring ISDN PRI” in the Signaling Configuration part of this guide.

.

Comparison of NextPort SPE and MICA Modem Commands

compare the MICA and SPE commands.

Table 2 EXEC Commands: NextPort to MICA Command Comparison

NextPort SPE Commands

Purpose

MICA Modem Commands

Clears specified ports.

Clears all log entries for specified ports.

Reboots all specified SPEs. All calls will be torn down.

Clears all statistics.

Clears all log entries for specified SPEs.

Displays configuration parameters for the current active session.

Displays port-level information for an active modem.

Displays the events generated by the modem sessions.

Displays port modem test results.

Displays statistics for the current active session.

Displays the SPE status.

Displays the SPE system log.

Displays the statistics of all active calls on specified SPEs.

Displays the call success rate (CSR) for the specified SPE.

Displays all modem disconnect reasons for the specified SPEs.

Displays the total number of connections negotiated within each modulation or coder-decoder (codec) for a specific range of SPEs.

Displays the total number of connections negotiated within each high modulation or codec for a specific range of SPEs or for all the SPEs.

Displays the connect-speeds negotiated within each low-speed modulation or codec for a specific range of SPEs or for all the SPEs.

Displays the total number of connections negotiated within each low modulation or codec for a specific range of SPEs or for all the SPEs.

Displays the modem service history statistics for specific SPEs.

Displays all MICA and NextPort firmware versions stored in flash memory and the firmware assigned to each SPE.

Table 3 SPE Configuration Commands: NextPort to MICA Command Comparison

NextPort SPE Commands

Purpose

MICA Modem Commands

Busies out active calls.

Specifies the firmware file to be upgraded.

Already implemented on the Cisco AS5300 and Cisco AS5800 platforms.

Specifies the upgrade method.

Already implemented on the Cisco AS5300 platform.

Enables modem autotest.

Tears down all active calls on the specified SPEs.

Configures the SPE.

Already implemented on the Cisco AS5300 and Cisco AS5800 platforms.

Generates a modem call record at the end of each call.

Sets the system country code.

Sets the maximum log entries for each port.

Sets the statistic polling interval.

3.Cisco does not recommend the use of the modem autotest or port modem autotest command. These commands may produce unexpected results including modems being marked out of service and unscheduled reloads. These commands have been removed in Cisco IOS Release 12.3.

3.Cisco does not recommend the use of the modem autotest or port modem autotest command. These commands may produce unexpected results including modems being marked out of service and unscheduled reloads. These commands have been removed in Cisco IOS Release 12.3.

Table 4 Port Configuration Commands: NextPort to MICA Command Comparison

NextPort SPE Commands

Purpose

MICA Modem Commands

Busies out a port.

Compares the value of the command to its default value.

Configures the port range.

Shuts down a port.

Table 5 Global Configuration Commands: NextPort to MICA Command Comparison

NextPort SPE CLI Commands

Purpose

MICA Modem CLI Commands

Defines a threshold to maintain a balance between the number of digital signal level 0s (DS0s) and modems.

Configuring Cisco Integrated Modems Using Modem Attention Commands

This section provides information about using modem attention (AT) command sets to modify modem configuration. It contains the following sections:

- Using Modem Dial Modifiers on Cisco MICA Modems (As required)

- Changing Configurations Manually in Integrated Microcom Modems (As required)

- Configuring Leased-Line Support for Analog Modems (As required)

Using Modem Dial Modifiers on Cisco MICA Modems

Dial modifiers permit multistage dialing for outbound modem calling through public and private switched telephone networks (PSTNs).

Note For additional information about dial modifiers for the MICA modems, search Cisco.com for the publication AT Command Set and Register Summary for MICA Six-Port Modules.

) character. These modifiers had been previously accepted without error but ignored in Cisco MICA modems on Cisco AS5300 and Cisco AS5800 universal access servers.

Table 6 Dial Modifiers for Cisco MICA Modems

Dial Modifier

Definition

dial modifier has been added to serve as a delimiter for the host when the dial string is processed. It allows Cisco MICA portware to be used in many environments that do not support DTMF dialing (for example, PRI).

modifiers cause Cisco MICA modems to wait for a dial tone.

in the dial string, or that the T1/E1 be configured for DTMF signaling.

generate the appropriate DTMF tones.

Changing Configurations Manually in Integrated Microcom Modems

You can change the running configuration of an integrated modem by sending individual modem AT commands. Manageable Microcom modems have an out-of-band feature, which is used to poll modem statistics and send AT commands. The Cisco IOS software uses a direct connect session to transfer information through this out-of-band feature. To send AT commands to a Microcom modem, you must permit a direct connect session for a specified modem, open a direct connect session, send AT commands to a modem, and clear the directly connected session from the modem when you are finished.

command, which hangs up a call. Open and close one direct connect session at a time. Note that multiple open sessions slow down modem performance.

Refer to the AT command set that came with your router for a complete list of AT commands that you can send to the modems.

For Microcom modems, you can clear or terminate an active directly connected session in two ways:

- Press Ctrl-C after sending all AT commands as instructed by the system when you enter AT command mode.

- Enter a second Telnet session and execute the clear modem at-mode slot / port EXEC command. This method is used for closing a directly connected session that may have been mistakenly left open by the first Telnet session.

The following example illustrates use of the modem commands.

AT Mode Example for Integrated Modems

to modem 1/1:

AS5200# modem at-mode 1/1

You are now entering AT command mode on modem (slot 1 / port 1).

Please type CTRL-C to exit AT command mode.

at%v

MNP Class 10 V.34/V.FC Modem Rev 1.0/85

OK

at\s

IDLE 000:00:00

LAST DIAL

NET ADDR: FFFFFFFFFFFF

MODEM HW: SA 2W United States

4 RTS 5 CTS 6 DSR - CD 20 DTR - RI

MODULATION IDLE

MODEM BPS 28800 AT%G0

MODEM FLOW OFF AT\G0

MODEM MODE AUT AT\N3

V.23 OPR. OFF AT%F0

AUTO ANS. ON ATS0=1

SERIAL BPS 115200 AT%U0

BPS ADJUST OFF AT\J0

SPT BPS ADJ. 0 AT\W0

ANSWER MESSGS ON ATQ0

SERIAL FLOW BHW AT\Q3

PASS XON/XOFF OFF AT\X0

PARITY 8N AT

The modem responds with “OK” when the AT command you send is received.

Configuring Leased-Line Support for Analog Modems

Analog modems on the NM-8AM and NM-16AM network modules in the Cisco 2600 and 3600 series routers provide two-wire leased-line support for enterprise customers who require point-to-point connections between locations and for enterprise customers with medium to high data transfer requirements without access to other technologies or with access to only low-grade phone lines.

This feature works only with leased lines that provide loop current. Each modem used must have an RJ-11 connection to the PSTN.

Several features enhance the analog modem software:

- 2-wire leased-line support.

- Modem speeds up to 33.6 kbps with support for all current analog modem protocols, compression, and error correction techniques.

- Power-on autoconnect and loopback testing.

- Support for the maximum number of leased-line users without data transmission loss at distances up to 2 to 5 km.

- In-band and out-of-band monitoring.

- Support on all Cisco 2600 and Cisco 3600 series platforms and upgradability using Cisco IOS software.

- Compatibility with other major leased-line modem vendors.

command for the appropriate leased lines.

}command:

- 0 —Disables the leased line (enables switched line; default).

- 1 —Enables the leased line. The modem initiates a leased line when dial and answer commands ( ATD and ATA ) are issued.

- 2 —Enables the leased line. The modem goes off hook automatically after T57 number of seconds in:

– Originate mode if ATS0 is 0.

– Answer mode if ATS0 is not equal to 0.

The following AT registers can also be set:

- AT:T57 —Number of seconds before going off hook in leased-line mode when the command AT&L2 is used (defaults to 6).

- AT:T79 —Number of autoretrains before the modem is disconnected (defaults to 3).

For more information about using the AT command set with the modems on the NM-8AM and NM-16AM network modules in the Cisco 2600 and 3600 series routers, search Cisco.com for the publication AT Command Set and Register Summary for Analog Modem Network Modules.

To configure a modem for leased-line operation, use the following commands in global configuration mode:

Command

Purpose

Step 1

Router(config)# modemcap entry modem-type-name :AA=S0=0&L2

Sets the modemcap for leased-line operation for the originating modem.

Step 2

Router(config)# modemcap entry modem-type-name :AA=S0=1&L2

Sets the modemcap for leased-line operation for the answering modem.

command lists all the predefined modem types and any user-defined modemcaps that are currently configured on the router:

- If the leased line has been configured, the modemcap information will be available.

- If the leased line has not been configured, only the predefined modem types will be displayed.

The important setting for leased-line support is what is defined in the modemcap as the key configuration item and its application to the leased line. Consider the following command strings:

modemcap entry micro_LL_orig:AA=S0=0&L2

modemcap entry micro_LL_ans:AA=S0=1&L2

stands for autoanswer:

- The answering modem AA register is set to 1 (AA=S0=1) so that autoanswer is “on”.

- The originating modem AA register is set to 0 (AA=S0=0) so that autoanswer is “off”.

AT command.

In the examples, the micro_LL_orig and micro_LL_ans strings are arbitrary text descriptions.

Note For the modemcap entry command, one of the predefined modem types may be used or a completely user-defined modemcap may be created. For leased line, no new modem type was added. Users may create their own modemcaps for leased-line functionality.

command. For each connection, each modem must be configured as an originator or answerer.

The following example shows modemcaps for a leased-line originator and answerer and their application to specific ports:

modemcap entry micro_LL_orig:AA=S0=0&L2

modemcap entry micro_LL_ans:AA=S0=1&L2

line 73

no exec

modem InOut

modem autoconfigure type micro_LL_ans

transport input all

line 74

no exec

modem InOut

modem autoconfigure type micro_LL_orig

transport input all

Note When Multilink PPP (MLP) is configured on a dialer interface, the dialer configuration has a default value of 2 minutes for dialer idle timeout. For leased-line connections, set the dialer idle timeout to infinity by adding dialer idle-timeout 0 to the configuration.

Verifying the Analog Leased-Line Configuration

command displays the progress of leased-line connections. Here is an example log for a leased-line answerer. Note the “LL Answering” state and “LL Answer” in the “Direction” field of the connection report:

00:44:03.884 DTR set high

00:44:02.888 Modem enabled

00:43:57.732 Modem disabled

00:43:52.476 Modem State:LL Answering

00:43:52.476 CSM:event-MODEM_STARTING_CONNECT New

State-CSM_CONNECT_INITIATED_STATE

00:43:51.112 Modem State:Waiting for Carrier

00:43:43.308 Modem State:Connected

00:43:42.304 Connection:TX/RX Speed = 33600/33600,

Modulation = V34

Direction = LL Answer, Protocol = MNP, Compression =

V42bis

00:43:42.304 CSM:event-MODEM_CONNECTED New

State-CONNECTED_STATE

00:43:42.300 RS232:noCTS* DSR* DCD* noRI noRxBREAK

TxBREAK*

00:43:41.892 PPP mode active

00:43:41.892 Modem enabled

00:43:39.888 PPP escape maps set:TX map=00000000 RX

map=FFFFFFFF

00:43:39.724 PPP escape maps set:TX map=00000000 RX

map=000A0000

00:43:34.444 RS232:CTS* DSR DCD noRI noRxBREAK TxBREAK

00:43:11.716 Modem Analog Report:TX = -20, RX = -34,

Signal to noise = 61

Cisco 2600 and 3600 Series Analog Modem Leased-Line Support Examples

In the following examples, one Cisco 3620 router and one Cisco 3640 router are connected back-to-back using leased lines. The Cisco 3620 router has the originating configuration, and the Cisco 3640 router has the answering configuration.

command is added to set the dialer idle timeout to be infinity. Otherwise the leased line will go down and up every 2 minutes because the default dialer interface idle timeout is 2 minutes.

Note Except for passwords and logins, the Cisco IOS command-line interface (CLI) is case-insensitive. For this document, an uppercase “L” has been used in the command examples to avoid confusion with the numeral “1”.

Leased-Line Originating Configuration

version 12.1

service timestamps debug uptime

service timestamps log uptime

!

modemcap entry micro_LL_orig:AA=S0=0&L2

modemcap entry micro_LL_ans:AA=S0=1&L2

!

interface Async33

no ip address

encapsulation ppp

no ip route-cache

no ip mroute-cache

dialer in-band

dialer pool-member 1

async default routing

async dynamic routing

async mode dedicated

no peer default ip address

no fair-queue

no cdp enable

ppp direction callout

ppp multilink

!

interface Dialer1

ip address 10.1.24.1 255.255.255.0

encapsulation ppp

no ip route-cache

no ip mroute-cache

dialer remote-name sara40

dialer pool 1

dialer idle-timeout 0

dialer max-call 4096

no cdp enable

ppp direction callout

ppp multilink

!

dialer-list 1 protocol ip permit

!

line con 0

exec-timeout 0 0

transport input none

line 33

no exec

modem InOut

modem autoconfigure type micro_LL_orig

transport input all

line aux 0

exec-timeout 0 0

line vty 0 4

exec-timeout 0 0

!

end

Leased-Line Answering Configuration

version 12.1

service timestamps debug uptime

service timestamps log uptime

!

modemcap entry micro_LL_orig:AA=S0=0&L2

modemcap entry micro_LL_ans:AA=S0=1&L2

!

interface Async73

no ip address

encapsulation ppp

no ip route-cache

no ip mroute-cache

dialer in-band

dialer pool-member 1

async default routing

async dynamic routing

async mode dedicated

no peer default ip address

no fair-queue

no cdp enable

ppp direction callout

ppp multilink

!

interface Dialer1

ip address 10.1.24.2 255.255.255.0

encapsulation ppp

no ip route-cache

no ip mroute-cache

load-interval 30

dialer remote-name sara20

dialer pool 1

dialer idle-timeout 0

dialer load-threshold 1 either

dialer max-call 4096

no cdp enable

ppp direction callout

ppp multilink

!

dialer-list 1 protocol ip permit

line con 0

exec-timeout 0 0

transport input none

line 73

no exec

modem InOut

modem autoconfigure type micro_LL_ans

transport input all

line aux 0

transport input all

flowcontrol hardware

line vty 0 4

exec-timeout 0 0

!

end

Configuring Modem Pooling

Modem pooling allows you to control which modem a call connects to, on the basis of dialed number identification service (DNIS). When modem pooling is not used, incoming and outgoing calls are arbitrarily assigned to modems. For example, consider a Cisco AS5300 access server loaded with a 4-port ISDN PRI card. After an analog modem call comes into the first PRI trunk, the call is greeted by a general pool of B channels and a general pool of modems. Any B channel can be connected to any modem in the access server. A random assignment takes place. Modem resources cannot be controlled.

Modem pooling assigns physical modems to a single DNIS. It enables you to create pools of physical modems in one access server, assign a unique DNIS to each modem pool, and set maximum simultaneous connect limits.

This feature is used for physically partitioning or virtually partitioning modems inside one network access server.

Modem pooling offers these benefits:

- A certain number of modem ports can be guaranteed per DNIS.

- Maximum simultaneous connection limits can be set for each DNIS.

The following restrictions apply:

- Modem pooling is not a solution for large-scale dial access. It cannot be used to create virtual modem pools across multiple access servers that are connected. Modem pooling is physically restricted to one access server.

- MICA and Microcom technology modems support modem pooling. However, only MICA modems support modem pooling for CT1 and CE1 configurations using CAS. To use modem pooling with CT1 or CE1 connections, you must reserve at least two modems in the default modem pool. These reserved modems decode DNIS before handing off calls to the modems assigned to modem pools.

EXEC commands to display the modem call failure and success ratio.

- No MIBs support modem pooling.

- The same DNIS cannot exist in more than one modem pool.

Modem pooling is supported on the Cisco AS5300 access servers. To configure and manage modems, perform the tasks in the following sections; all tasks are optional and depend upon the needs of your system.

- Creating a Modem Pool (Required)

- Verifying Modem Pool Configuration (As required)

Creating a Modem Pool

You must first decide to physically partition or virtually partition your modems. For more information, see the previous section, “Configuring Modem Pooling.” After you have made this decision, create a modem pool for a dial-in service or specific customer by using the following commands beginning in global configuration mode.

Command

Purpose

Step 1

Creates a modem pool and assigns it a name, and starts modem pool configuration mode.

Step 2

) is required between the two numbers. The range of modems you can choose from is equivalent to the number of modems in your access server that are not currently associated with another modem pool.

Step 3

]

Assigns the DNIS to be used for this modem pool.

value, the default (total number of modems in the pool) is used.4

Step 4

Returns to EXEC mode.

Step 5

Displays the running configuration to verify the modem pool settings. Make changes accordingly.

Step 6

Saves the running configuration to the startup configuration.

4.The DNIS string can have an integer x to indicate a “don’t care” digit for that position, for example, 555010x.

4.The DNIS string can have an integer x to indicate a “don’t care” digit for that position, for example, 555010x.

Note If you have active modem calls on the access server before using modem pooling, modem pooling gracefully applies itself to the access server. Modem pooling first waits for active calls to hang up before assigning modems to modem pools and directing calls according to DNIS.

Verifying Modem Pool Configuration

for a description of each display field.

Router# show modem-pool

modem-pool: System-def-Mpool

modems in pool: 0 active conn: 0

0 no free modems in pool

modem-pool: v90service

modems in pool: 48 active conn: 46

8 no free modems in pool

called_party_number: 1234

max conn allowed: 48, active conn: 46

8 max-conn exceeded, 8 no free modems in pool

modem-pool: v34service

modems in pool: 48 active conn: 35

0 no free modems in pool

called_party_number: 5678

max conn allowed: 48, active conn: 35

0 max-conn exceeded, 0 no free modems in pool

Table 7 show modem-pool Field Descriptions

Field

Description

command.

All the modems not assigned to a modem pool are automatically assigned to the system default pool (displayed as System-def-Mpool).

Number of modems assigned to the modem pool. To assign modems to a pool, refer to the display and descriptions for the pool-range command.

Number of simultaneous active connections for the specified modem pool or called party DNIS number.

Number of times incoming calls were rejected because there were no more free modems in the pool to accept the call.

command.

command.

command was exceeded.

For modem pool configuration examples, see the section “Physical Partitioning with Dial-In and Dial-Out Scenario” later in this chapter.

Check the following if you are having trouble operating your modem:

- Make sure you have not configured the same DNIS for multiple pools.

- Make sure you have not placed the same modem in multiple pools.

Note Modem pools that use MICA or Microcom modems support incoming analog calls over ISDN PRI. However, only MICA modems support modem pooling for T1 and E1 configurations with CAS.

Configuring Physical Partitioning

You can either physically partition or virtually partition your modems to enable different dial-in and dial-out services. This section provides information about the following optional tasks:

- Creating a Physical Partition

- Physical Partitioning with Dial-In and Dial-Out Scenario

Physical partitioning uses one access server to function as multiple access servers loaded with different types of modem services (for example, V.34 modems, fax-capable modems, and point-of-sale (POS) modems). Each modem service is part of one physical modem pool and is assigned a unique DNIS number. (See Figure 2.)

Figure 2 Modem Pooling Using Physical Partitioning

Physical partitioning can also be used to set up an access server for bidirectional dial access. (See Figure 3.)

Figure 3 shows one Cisco AS5300 access server loaded with 96 MICA modems and configured with 2 modem pools. One modem pool has 84 modems and collects DNIS. This pool is shared by 400 salespeople who remotely download e-mail from headquarters. The other modem pool contains 12 fax-capable modems and does not collect DNIS. This pool is shared by 40 employees using PCs on a LAN. Each time an outbound call is initiated by a PC, a modem on the Cisco AS5300 access server is seized and used to fax out or dial out. Not configuring DNIS support in the fax-out modem pool protects the pool from being used by the calls coming in from the field. Regardless of how many salespeople are dialing in or which telephone number they use, the fax-out and dial-out modem pool will always be reserved for the PCs connected to the LAN.

Figure 3 Modem Pooling Used for Bidirectional Dialing

Creating a Physical Partition

The following task creates one V.34 modem pool and one 56K modem pool on a Cisco AS5200. Each modem pool is configured with its own DNIS. Depending on which DNIS the remote clients dial, they connect to a 56K MICA modem or a V.34 Microcom modem.

The following hardware configuration is used on the Cisco AS5200 access server:

- One 2-port T1 PRI card

- One 48-port card containing four 6-port MICA 56K modem modules and two 12-port Microcom V.34 modem modules

To configure basic physical partitioning, perform the following steps:

Step 1 Enter global configuration mode:

Router# configure terminal

Router(config)#

command. The modem pool is called 56kservices, which spans four 6-port MICA 56K modem modules.

Router(config)# modem-pool 56kservices

Router(config-modem-pool)#

Note The router is in modem pool configuration mode after the prompt changes from Router(config)# to Router(config-modem-pool)#.

EXEC command to determine the TTY line numbering scheme for your access server.

Router(config-modem-pool)# pool-range 1-24

command. This example uses the DNIS 5550101 to connect to the 56K modems. The maximum simultaneous connection limit is set to 24. The 25th user who dials 5550101 gets a busy signal.

Router(config-modem-pool)# called-number 5550101 max-conn 24

command. In the following example, 56K modems are in the modem pool called 56kservices. The remaining 24 V.34 Microcom modems are still in the default system pool.

Router(config-modem-pool)# ^Z

Router# show modem-pool

modem-pool: System-def-Mpool

modems in pool: 24 active conn: 0

0 no free modems in pool

modem-pool: 56kservices

modems in pool: 24 active conn: 0

0 no free modems in pool

called_party_number: 5550101

max conn allowed: 24, active conn: 0

0 max-conn exceeded, 0 no free modems in pool

command shows that there are no remaining modems in the system default modem pool.

Router# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)# modem-pool v34services

Router(config-modem-pool)# pool-range 25-48

Router(config-modem-pool)# called-number 5550202 max-conn 24

Router(config-modem-pool)# ^Z

Router# show modem-pool

modem-pool: System-def-Mpool

modems in pool: 0 active conn: 0

0 no free modems in pool

modem-pool: 56kservices

modems in pool: 48 active conn: 0

0 no free modems in pool

called_party_number: 5550101

max conn allowed: 48, active conn: 0

0 max-conn exceeded, 0 no free modems in pool

modem-pool: v34services

modems in pool: 48 active conn: 0

0 no free modems in pool

called_party_number: 5550202

max conn allowed: 48, active conn: 0

0 max-conn exceeded, 0 no free modems in pool

Router# copy running-config startup-config

Physical Partitioning with Dial-In and Dial-Out Scenario

The following is a bidirectional dial scenario using a Cisco AS5300 access server. Two modem pools are configured. One modem pool contains 84 56K MICA modems, which is shared by 400 remote salespeople who dial in to headquarters. The other modem pool contains 12 fax-capable modems, which are shared by 40 employees who dial out of the headquarters LAN using the Cisco DialOut Utility software. See Figure 3 for the network topology.

The following hardware configuration is used on the Cisco AS5300:

- One 4-port T1 PRI card

- Two 48-port cards containing fourteen 6-port MICA 56K modem modules and two 6-port MICA fax-capable modem modules

To configure physical partitioning with dial-in and dial-out capability, perform the following steps:

line configuration command is used to prevent modems 1 to 84 from dialing out.

Router# configure terminal

Router(config)# modem-pool 56ksalesfolks

Router(config-modem-pool)# pool-range 1-84

Router(config-modem-pool)# called-number 5550303 max-conn 84

Router(config-modem-pool)# exit

Router(config)# line 1 84

Router(config-line)# modem dialin

Router(config-line)# transport input all

Router(config-line)# rotary 1

Router(config-line)# autoselect ppp

Router(config-line)# exit

Router(config)#

Step 2 Create the dial-out/fax-out modem pool for the 40 local employees connected to the headquarters LAN. This modem pool contains 12 fax-capable MICA modems. No DNIS is assigned to the pool. Because lines 85 to 96 are used for the dial-out and fax-out modem services, the asynchronous lines are configured for reverse Telnet. This configuration is needed for the Telnet extensions to work with the dial-out application, which is installed on the LAN PCs.

Router(config)# modem-pool dialoutfolks

Router(config-modem-pool)# pool-range 85-96

Router(config-modem-pool)# exit

Router(config)# line 85-96

Router(config-line)# refuse-message z [!NMM!] No Modems Available z

Router(config-line)# exec-timeout 0 0

Router(config-line)# autoselect during-login

Router(config-line)# autoselect ppp

Router(config-line)# modem inout

Router(config-line)# rotary 1

Router(config-line)# transport preferred telnet

Router(config-line)# transport input all

Router(config-line)# exit

Router(config)#

Step 3 Configure the group asynchronous interface, which assigns core protocol characteristics to all the asynchronous interfaces in the system. Regardless of the direction that the modems are dialing, all modems in the access server leverage this group asynchronous configuration.

Router(config)# interface group-async 1

Router(config-if)# ip unnumbered ethernet 0

Router(config-if)# encapsulation ppp

Router(config-if)# async mode interactive

Router(config-if)# ppp authentication chap pap paplocal

Router(config-if)# peer default ip address pool bidir_dial_pool

Router(config-if)# no cdp enable

Router(config-if)# no ip mroute cache

Router(config-if)# no ip route cache

Router(config-if)# async dynamic routing

Router(config-if)# async dynamic address

Router(config-if)# group range 1-96

Building configuration...

Router(config-if)# exit

Step 4 Create an IP address pool for all the dial-in clients and dial-out clients. Both types of clients borrow addresses from this shared pool.

Router(config)# ip local pool bidir_dial_pool 10.4.1.1 10.4.1.96

Router(config)# ^z

Router# copy running-config startup-config

Step 5 (Optional) If you are using CiscoSecure AAA and a remote TACACS server, include the following security statements on the access server:

Router(config)# aaa new-model

Router(config)# aaa authentication login default tacacs+

Router(config)# aaa authentication login noaaa local

Router(config)# aaa authentication login logintac tacacs+

Router(config)# aaa authentication ppp ppptac tacacs+

Router(config)# aaa authentication ppp paplocal local

Router(config)# aaa authorization exec tacacs+

Router(config)# aaa authorization network tacacs+

Router(config)# aaa authorization reverse-access tacacs+

Router(config)# aaa accounting exec start-stop tacacs+

Router(config)# aaa accounting network start-stop tacacs+

Router(config)# aaa accounting update newinfo

Router(config)# enable password cisco

You should also include the host name, timeout interval, and authentication key:

Router(config)# tacacs-server host 10.4.1.10

Router(config)# tacacs-server timeout 20

Router(config)# tacacs-server key nas1

Configuring Virtual Partitioning

Virtual partitioning creates one large modem pool on one access server, but assigns different DNIS numbers to different customers. Each incoming DNIS consumes resources from the same modem pool, but a maximum connect option is set for each DNIS.

Figure 4 shows two Internet service provider (ISP) customers who are leasing modems from another service provider. Each ISP is assigned its own DNIS number and range of modems. Each ISP is guaranteed a certain number of physical modem ports for simultaneous connections. After an ISP uses up all the modems assigned to its DNIS, a busy signal is issued.

Figure 4 Modem Pooling Using Virtual Partitioning

Virtual partitioning essentially resells modem banks to customers, such as a small-sized ISP. However, remember that modem pooling is a single-chassis solution, not a multichassis solution. Modem pooling is not a solution for reselling ports on a large-scale basis.

The following procedure creates one modem pool on a Cisco AS5300 access server for two ISP customers. The shared modem pool is called isp56kpool. However, both ISP customers are assigned different DNIS numbers and are limited to a maximum number of simultaneous connections.

See Figure 4 for the network topology.

The following hardware configuration is used on the Cisco AS5300 access server:

- One 4-port T1 PRI card

- Two 48-port cards containing sixteen 6-port MICA 56K modem modules

To configure virtual partitioning, perform the following steps:

Step 1 Enter global configuration mode:

Router# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)#

Step 2 Create the shared modem pool for the 56K MICA modem services. This modem pool is called isp56kpool, which spans sixteen 6-port MICA 56K modem modules.

Router(config)# modem-pool isp56kpool

Router(config-modem-pool)#

EXEC command to determine your TTY line numbering scheme.

Router(config-modem-pool)# pool-range 1-96

option limits each ISP to 48 simultaneous connections. The 49th user to dial either DNIS will get a busy signal.

Router(config-modem-pool)# called-number 5550101 max-conn 48

Router(config-modem-pool)# called-number 5550202 max-conn 48

command. In the following example, all the 56K modems are in the isp56kpool modem pool. The output also shows two DNIS numbers configured: 5550101 and 5550202.

Router(config-modem-pool)# ^Z

Router# show modem-pool

modem-pool: System-def-Mpool

modems in pool: 0 active conn: 0

0 no free modems in pool

modem-pool: isp56kpool

modems in pool: 96 active conn: 0

0 no free modems in pool

called_party_number: 5550101

max conn allowed: 48, active conn: 0

0 max-conn exceeded, 0 no free modems in pool

called_party_number: 5550202

max conn allowed: 48, active conn: 0

0 max-conn exceeded, 0 no free modems in pool

Router# copy running-config startup-config

Configuring Call Tracker

The Call Tracker feature captures detailed statistics on the status and progress of active calls and retains historical data for disconnected call sessions. Call Tracker collects session information such as call states and resources, traffic statistics, total bytes transmitted and received, user IP address, and disconnect reason. This data is maintained within the Call Tracker database tables, which are accessible through the Simple Network Management Protocol (SNMP), the CLI, or syslog.

Note The calltracker command, providing Call Tracker services, is supported for dial calls but not voice. Calltracker is supported for dial calls on 5x platforms (5300, 5350, 5400, 5800, and 5850).

Call Tracker is notified of applicable call events by related subsystems such as ISDN, PPP, CSM, Modem, EXEC, or TCP-Clear. SNMP traps are generated at the start of each call, when an entry is created in the active table, and at the end of each call, when an entry is created in the history table. Call Record syslogs are available through configuration that will generate detailed information records for all call terminations. This information can be sent to syslog servers for permanent storage and future analysis.

To configure Call Tracker, perform the following steps:

Command

Purpose

Step 1

Enables Call Tracker.

Step 2

]

Enables Call Tracker syslog support for generating detailed Call Records.

Step 3

Sets the maximum number of call entries to store in the Call Tracker history table.

Step 4

Sets the number of minutes for which calls are stored in the Call Tracker history table.

Step 5

Sets the maximum packet size allowed for SNMP server requests and replies.

Step 6

Sets the queue length for SNMP traps.

Step 7

Enables Call Tracker to send traps whenever a call starts or ends.

Step 8

Specifies the name or Internet address of the host to send Call Tracker traps.

Verifying Call Tracker

To verify the operation of Call Tracker, use the the following command in EXEC mode:

Command

Purpose

Verifies the Call Tracker configuration and current status.

Enabling Call Tracker

The following example shows how to enable the Call Tracker feature:

calltracker enable

calltracker call-record terse

calltracker history max-size 50

calltracker history retain-mins 5000

!

snmp-server engineID local 0012345

snmp-server community public RW

snmp-server community private RW

snmp-server community wxyz123 view v1default RO

snmp-server trap-source FastEthernet0

snmp-server packetsize 17940

snmp-server queue-length 200

snmp-server location SanJose

snmp-server contact Bob

snmp-server enable traps snmp

snmp-server enable traps calltracker

snmp-server enable traps isdn call-information

snmp-server enable traps hsrp

snmp-server enable traps config

snmp-server enable traps entity

snmp-server enable traps envmon

snmp-server enable traps bgp

snmp-server enable traps ipmulticast-heartbeat

snmp-server enable traps rsvp

snmp-server enable traps frame-relay

snmp-server enable traps rtr

snmp-server enable traps syslog

snmp-server enable traps dlsw

snmp-server enable traps dial

snmp-server enable traps dsp card-status

snmp-server enable traps voice poor-qov

snmp-server host 10.255.255.255 wxyz123

snmp-server host 10.0.0.0 xxxyyy calltracker

!

radius-server host 172.16.0.0 auth-port 1645 acct-port 1646 non-standard

radius-server key xyz

!

Configuring Polling of Link Statistics on MICA Modems

The status and diagnostic data that is routinely collected from MICA modems is expanded to include new link statistics for active calls, such as the attempted transmit and receive rates, the maximum and minimum transmit and receive rates, and locally and remotely issued retrains and speedshift counters. This connection data is polled from the modem at user-defined intervals and passed to Call Tracker.

To poll modem link statistics, use the following command in global configuration mode:

Command

Purpose

Sets the polling interval at which link statistics for active calls are retrieved from the modem.

Note The modem link-info poll time command consumes a substantial amount of memory, approximately 500 bytes for each MICA modem call. Use this command only if you require the specific data that it collects; for instance, if you have enabled Call Tracker on your access server.

Configuring MICA In-Band Framing Mode Control Messages

Dial-in Internet connections typically start in character mode to allow the user to log in and select a preferred service. When Cisco IOS software determines that the user wants a framed interface protocol during the call, such as PPP or SLIP, commands are sent to the MICA modem so that it will provide hardware assistance with the framing. This hardware assistance reduces the Cisco IOS processing load. To avoid loss or misinterpretation of framed data during the transition, issue these commands at precise times with respect to the data being sent and received.

MICA modem framing commands can be sent in the data stream itself, which greatly simplifies Cisco IOS tasks in achieving precision timing. For PPP connections, the common way for modems to connect to the Internet, total connect time might typically be improved by 2 to 3 seconds. This functionality reduces timeouts during PPP startup and reduces startup time. If an ASCII banner is sent just before PPP startup, this feature eliminates problems with banner corruption such as truncation and extraneous characters, thus improving the performance of terminal equipment.

In earlier software, the modem interface timing rules were not well understood and were difficult or impossible to implement using the separate command interface of the modem. The practical result is that the MICA in-band framing mode reduces the number of timeouts during PPP startup, and thus reduces startup time. MICA in-band framing is supported on MICA modems in Cisco AS5300 and Cisco AS5800 access servers.

To configure the MICA in-band framing mode control messages, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

]

Specifies the number of modem lines to configure and enters line configuration mode. If a range is entered, it must be equal to the number of modems in the router.

Step 2

Improves PPP and SLIP startup.

Normally a router avoids line and modem noise by clearing the initial data received within the first one or two seconds. However, when the autoselect PPP feature is configured, the router flushes characters initially received and then waits for more traffic. This flush causes timeout problems with applications that send only one carriage return.

The Cisco IOS software offers additional interface commands that can be set to control modem interface timing. Refer to the Cisco IOS command references for more information about the interface commands described in the following paragraphs.

command expires, the down state is effectively filtered, and the rest of the software on the switch is not aware that a link-down event occurred. Therefore, a large carrier delay timer results in fewer link-up and link-down events being detected. On the other hand, setting the carrier delay time to 0 means that every link-up and link-down event is detected.

command enable pulsing DTR signal intervals on serial interfaces, and is useful for handling encrypting or other similar devices that toggle the DTR signal to resynchronize.

interface command.

Enabling Modem Polling

The following example enables modem status polling through the out-of-band feature, which is associated to line 1:

Router# configure terminal

Router(config)# line 1

Router(config-line)# modem status-poll

Setting Modem Poll Intervals

configuration command:

Router# configure terminal

Router(config)# modem poll time 10

Setting Modem Poll Retry

The following example configures the server to attempt to retrieve statistics from a local modem up to five times before discontinuing the polling effort:

Router# configure terminal

Router(config)# modem poll retry 5

Collecting Modem Statistics

EXEC command appropriate for your modem type and the task you want to perform.

Logging EIA/TIA Events

To facilitate meaningful analysis of the modem log, turn the storage of specific types of EIA/TIA events on or off. To activate or inactivate the storage of a specific type of EIA/TIA modem event for a specific line or set of lines, use either of the following commands in line configuration mode, as needed:

Command

Purpose

or

}

Configures the types of EIA/TIA events that are stored in the modem log. The default setting stores no EIA/TIA events.

Turns off the logging of a specific type of EIA/TIA event.

Configuring a Microcom Modem to Poll for Statistics

Manageable Microcom modems have an out-of-band feature, which is used for polling modem statistics. To configure the system to poll for modem statistics, use the following commands in global configuration mode:

Command

Purpose

Step 1

Specifies the number of seconds between statistical modem polling for Microcom modems. The default is 12 seconds. The configuration range is from 2 to 120 seconds.

Step 2

Sets the maximum number of polling attempts to Microcom modems. The default is three polling attempts. The configuration range is from 0 to 10 attempts.5

Step 3

Polls for status and statistics for a Microcom modem through the modem’s out-of-band feature.

Step 4

command to display modem events.

5.If the number of attempts to retrieve modem status or statistics exceeds the number you define, the out-of-band feature is removed from operation. In this case, you must reset the modem hardware using the clear modem command.

5.If the number of attempts to retrieve modem status or statistics exceeds the number you define, the out-of-band feature is removed from operation. In this case, you must reset the modem hardware using the clear modem command.

Troubleshooting Using a Back-to-Back Modem Test Procedure

You can manually isolate an internal back-to-back connection and data transfer between two modems for focused troubleshooting purposes. For example, if mobile users cannot dial in to modem 2/5 (which is the sixth modem port on the modem board in the second chassis slot), attempt a back-to-back test with modem 2/5 and a modem known to be functioning, such as modem 2/6. You might need to enable this command on several different combinations of modems to determine which one is not functioning properly. A pair of operable modems connect and complete sending data in both directions. An operable modem and an inoperable modem do not connect with each other.

command, as follows:

Step 1 Perform a back-to-back modem test between two normal functioning modems. This example shows a successful connection between modem 1/1 and modem 1/0, which verifies normal operating conditions between these two modems:

Router# test modem back-to-back 1/1 1/0

Repetitions (of 10-byte packets) [1]: 10

Router#

%MODEM-5-B2BCONNECT: Modems (1/1) and (1/0) connected in back-to-back test: CONN

ECT9600/REL-MNP

%MODEM-5-B2BMODEMS: Modems (1/0) and (1/1) completed back-to-back test: success/

packets = 20/20

the number you originally specify.

When a known good modem is tested against a known bad modem, the back-to-back modem test fails. In the following example, modem 1/3 is suspected or proven to be inoperable or bad:

Router# test modem back-to-back 1/1 1/3

Repetitions (of 10-byte packets) [1]: 10

Router#

%MODEM-5-BADMODEMS: Modems (1/3) and (1/1) failed back-to-back test: NOCARRIER

) is used for modem 1/3:

Router# show modem 1/3

Mdm Typ Status Tx/Rx G Duration TX RX RTS CTS DSR DCD DTR

1/3 V34 Idle 28800/28800 0 00:00:00 x x x x x

Modem 1/3, Microcom MNP10 V34 Modem (Managed), TTY4

Firmware (Boot) Rev: 1.0(23) (1.0(5))

Modem config: Incoming and Outgoing

Protocol: reliable/MNP, Compression: V42bis

Management port config: Status polling and AT session

Management port status: Status polling and AT session

TX signals: -15 dBm, RX signals: -17 dBm

Last clearing of "show modem" counters never

0 incoming completes, 0 incoming failures

0 outgoing completes, 0 outgoing failures

0 failed dial attempts, 0 ring no answers, 1 busied outs

0 no dial tones, 0 dial timeouts, 0 watchdog timeouts

0 no carriers, 0 link failures, 0 resets, 0 recover oob

0 protocol timeouts, 0 protocol errors, 0 lost events

Transmit Speed Counters:

Connection Speeds 75 300 600 1200 2400 4800

# of connections 0 0 0 0 0 0

Connection Speeds 7200 9600 12000 14400 16800 19200

# of connections 0 0 0 0 0 0

Connection Speeds 21600 24000 26400 28800 31200 32000

# of connections 0 0 0 1 0 0

Connection Speeds 33600 34000 36000 38000 40000 42000

# of connections 0 0 0 0 0 0

Connection Speeds 44000 46000 48000 50000 52000 54000

# of connections 0 0 0 0 0 0

Connection Speeds 56000

# of connections 0

command on line 4:

Router# configure terminal

Router(config)# line 4

Router(config-line)# modem bad

Router(config-line)# exit

Router(config)# exit

command to display the bad modem status.

command display output.

Router# show modem

%SYS-5-CONFIG_I: Configured from console by consolem

Inc calls Out calls Busied Failed No Succ

Mdm Usage Succ Fail Succ Fail Out Dial Answer Pct.

1/0 0% 0 0 0 0 1 0 0 0%

1/1 0% 0 0 0 0 3 0 0 0%

1/2 0% 0 0 0 0 1 0 0 0%

B 1/3 0% 0 0 0 0 1 0 0 0%

1/4 0% 0 0 0 0 1 0 0 0%

1/5 0% 0 0 0 0 1 0 0 0%

1/6 0% 0 0 0 0 1 0 0 0%

1/7 0% 0 0 0 0 1 0 0 0%

1/8 0% 0 0 0 0 1 0 0 0%

1/9 0% 0 0 0 0 1 0 0 0%

1/10 0% 0 0 0 0 1 0 0 0%

1/11 0% 0 0 0 0 1 0 0 0%

1/12 0% 0 0 0 0 1 0 0 0%

1/13 0% 0 0 0 0 1 0 0 0%

1/14 0% 0 0 0 0 1 0 0 0%

1/15 0% 0 0 0 0 1 0 0 0%

1/16 0% 0 0 0 0 1 0 0 0%

1/17 0% 0 0 0 0 1 0 0 0%

1/18 0% 0 0 0 0 0 0 0 0%

1/19 0% 0 0 0 0 0 0 0 0%

1/20 0% 0 0 0 0 0 0 0 0%

1/21 0% 0 0 0 0 0 0 0 0%

1/22 0% 0 0 0 0 0 0 0 0%

1/23 0% 0 0 0 0 0 0 0 0%

command display output, as the following example shows:

Router# show modem 1/3

Mdm Typ Status Tx/Rx G Duration TX RX RTS CTS DSR DCD DTR

1/3 V34 Bad 28800/28800 0 00:00:00 x x x x x

Modem 1/3, Microcom MNP10 V34 Modem (Managed), TTY4

Firmware (Boot) Rev: 1.0(23) (1.0(5))

Modem config: Incoming and Outgoing

Protocol: reliable/MNP, Compression: V42bis

Management port config: Status polling and AT session

Management port status: Status polling and AT session

TX signals: -15 dBm, RX signals: -17 dBm

Last clearing of "show modem" counters never

0 incoming completes, 0 incoming failures

0 outgoing completes, 0 outgoing failures

0 failed dial attempts, 0 ring no answers, 1 busied outs

0 no dial tones, 0 dial timeouts, 0 watchdog timeouts

0 no carriers, 0 link failures, 0 resets, 0 recover oob

0 protocol timeouts, 0 protocol errors, 0 lost events

Transmit Speed Counters:

Connection Speeds 75 300 600 1200 2400 4800

# of connections 0 0 0 0 0 0

Connection Speeds 7200 9600 12000 14400 16800 19200

# of connections 0 0 0 0 0 0

Connection Speeds 21600 24000 26400 28800 31200 32000

# of connections 0 0 0 1 0 0

Connection Speeds 33600 34000 36000 38000 40000 42000

# of connections 0 0 0 0 0 0

Connection Speeds 44000 46000 48000 50000 52000 54000

# of connections 0 0 0 0 0 0

Connection Speeds 56000

# of connections 0

Clearing a Direct Connect Session on a Microcom Modem

The examples in this section are for Microcom modems.

command from a Telnet session:

Router# modem at-mode 1/1

command from a second Telnet session while the first Telnet session is connected to the modem:

Router# clear modem at-mode 1/1

clear "modem at-mode" for modem 1/1 [confirm] <press Return>

Router#

The following output is displayed in the first Telnet session after the modem is cleared by the second Telnet session:

Direct connect session cleared by vty0 (172.19.1.164)

Displaying Local Disconnect Reasons

EXEC command.

Local disconnect reasons are listed across the top of the screen display (for example, wdogTimr, compress, retrain, inacTout, linkFail, moduFail, mnpProto, and lapmProt). In the body of the screen display, the number of times each modem disconnected is displayed (see the # column). For a particular disconnect reason, the % column indicates the percent that a modem was logged for the specified disconnect reason with respect to the entire modem pool for that given reason. For example, out of all the times the rmtLink error occurred on all the modems in the system, the rmtLink error occurred 10 percent of the time on modem 0/22.

Malfunctioning modems are detected by an unusually high number of disconnect counters for a particular disconnect reason. For example, if modem 1/0 had a high number of compression errors compared to the remaining modems in system, modem 1/0 would likely be the inoperable modem.

command.

Note For a complete description of each error field displayed by the commands on this page, refer to the Cisco IOS Dial Technologies Command Reference. Remote disconnect reasons are not described by the show modem command output.

command. Because of the screen size limitation of most terminal screen displays, not all possible disconnect reasons are displayed at one time. Only the top eight most frequently experienced disconnect reasons are displayed at one time.

Router# show modem call-stats

dial-in/dial-out call statistics

lostCarr dtrDrop rmtLink wdogTimr compress retrain inacTout linkFail

Mdm # % # % # % # % # % # % # % # %

* 0/0 6 2 2 3 1 0 0 0 0 0 0 0 0 0 0 0

* 0/1 5 2 2 3 2 1 0 0 0 0 0 0 0 0 0 0

0/2 5 2 2 3 4 3 0 0 0 0 0 0 0 0 0 0

* 0/3 5 2 2 3 2 1 0 0 0 0 0 0 0 0 0 0

* 0/4 5 2 1 1 1 0 0 0 0 0 0 0 0 0 0 0

* 0/5 5 2 2 3 2 1 0 0 0 0 0 0 0 0 0 0

* 0/6 4 1 2 3 2 1 0 0 0 0 0 0 0 0 0 0

* 0/7 4 1 2 3 4 3 0 0 0 0 0 0 0 0 0 0

* 0/8 6 2 1 1 3 2 0 0 0 0 0 0 0 0 0 0

* 0/9 5 2 1 1 1 0 0 0 0 0 0 0 0 0 0 0

* 0/10 5 2 1 1 2 1 0 0 0 0 0 0 0 0 0 0

* 0/11 5 2 1 1 2 1 0 0 0 0 0 0 0 0 0 0

0/12 5 2 2 3 2 1 0 0 0 0 0 0 0 0 0 0

* 0/13 5 2 1 1 1 0 0 0 0 0 0 0 0 0 0 0

* 0/14 5 2 1 1 1 0 0 0 0 0 0 0 0 0 0 0

* 0/15 5 2 1 1 1 0 0 0 0 0 0 0 0 0 0 0

* 0/16 5 2 1 1 1 0 0 0 0 0 0 0 0 0 0 0

* 0/17 5 2 1 1 2 1 0 0 0 0 0 0 0 0 0 0

* 0/18 5 2 1 1 2 1 0 0 0 0 0 0 0 0 0 0

* 0/19 5 2 1 1 3 2 0 0 0 0 0 0 0 0 0 0

* 0/20 5 2 1 1 1 0 0 0 0 0 0 0 0 0 0 0

* 0/21 5 2 1 1 1 0 0 0 0 0 0 0 0 0 0 0

* 0/22 5 2 1 1 11 10 0 0 0 0 0 0 0 0 0 0

* 0/23 5 2 1 1 2 1 0 0 0 0 0 0 0 0 0 0

* 2/0 4 1 2 3 2 1 0 0 0 0 0 0 0 0 0 0

* 2/1 5 2 1 1 2 1 0 0 0 0 0 0 0 0 0 0

* 2/2 5 2 2 3 0 0 0 0 0 0 0 0 0 0 0 0

* 2/3 5 2 1 1 2 1 0 0 0 0 0 0 0 0 0 0

* 2/4 5 2 1 1 2 1 0 0 0 0 0 0 0 0 0 0

* 2/5 5 2 1 1 2 1 0 0 0 0 0 0 0 0 0 0

* 2/6 4 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0

* 2/7 5 2 1 1 1 0 0 0 0 0 0 0 0 0 0 0

* 2/8 5 2 1 1 1 0 0 0 0 0 0 0 0 0 0 0

* 2/9 4 1 1 1 2 1 0 0 0 0 0 0 0 0 0 0

* 2/10 5 2 1 1 0 0 0 0 0 0 0 0 0 0 0 0

* 2/11 5 2 1 1 5 4 0 0 0 0 0 0 0 0 0 0

* 2/12 5 2 1 1 2 1 0 0 0 0 0 0 0 0 0 0

* 2/13 5 2 1 1 1 0 0 0 0 0 0 0 0 0 0 0

* 2/14 5 2 1 1 2 1 0 0 0 0 0 0 0 0 0 0

* 2/15 4 1 1 1 3 2 0 0 0 0 0 0 0 0 0 0

* 2/16 4 1 1 1 3 2 0 0 0 0 0 0 0 0 0 0

* 2/17 5 2 2 3 9 8 0 0 0 0 0 0 0 0 0 0

* 2/18 4 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0

* 2/19 3 1 1 1 2 1 0 0 0 0 0 0 0 0 0 0

* 2/20 7 3 1 1 8 7 0 0 0 0 0 0 0 0 0 0

* 2/21 5 2 1 1 1 0 0 0 0 0 0 0 0 0 0 0

* 2/22 4 1 1 1 2 1 0 0 0 0 0 0 0 0 0 0

* 2/23 5 2 1 1 2 1 0 0 0 0 0 0 0 0 0 0

Total 233 59 110 0 0 0 0 0

dial-out call statistics

noCarr noDitone busy abort dialStrg autoLgon dialTout rmtHgup

Mdm # % # % # % # % # % # % # % # %

* 0/0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0/2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/3 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/4 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/6 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/7 5 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/9 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/11 5 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0/12 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/13 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/14 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/15 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/16 2 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/17 4 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/18 5 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/19 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/20 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/21 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/22 5 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 0/23 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/0 2 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/1 3 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/5 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/6 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/7 4 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/8 7 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/9 4 1 1 1 2 1 0 0 0 0 0 0 0 0 0 0

* 2/10 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/11 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/12 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/13 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/14 4 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/15 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/16 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/17 5 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/18 5 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/19 3 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/20 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/21 4 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/22 2 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* 2/23 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Total 84 0 0 0 0 0 0 0

Removing Inoperable Modems

To manually remove inoperable modems from dialup services, use the following commands in line configuration mode:

Command

Purpose

Step 1

Removes and idles the modem from service and indicates it as suspected or proven to be inoperable.

Step 2

Resets and isolates the modem hardware for extensive troubleshooting.

Step 3

Abruptly shuts down a modem from dial service.

Step 4

Sets the maximum amount of time for which the call-switching module waits for a local modem to respond to a request before it is considered locked in a suspended state. The default is 5 minutes.

command.

Note Only idle modems can be marked “bad” by the modem bad command. If you want to mark a modem bad that is actively supporting a call, first enter the modem shutdown command, then enter the modem bad command.

command.

The following example disables a suspended modem and resets its hardware initialization:

Router# configure terminal

Router(config)# line 4

Router(config-line)# modem hold-reset

Router(config-line)# no modem hold-reset

The following example gracefully disables the modem associated with line 1 from dialing and answering calls. The modem is disabled only after all active calls on the modem are dropped.

Router# configure terminal

Router(config)# line 1

Router(config)# modem busyout

The following example abruptly shuts down the modem associated with line 2. All active calls on the modem are dropped immediately.

Router# configure terminal

Router(config)# line 2

Router(config)# modem shutdown

command to take the modem out of service.

Router# show modem

Inc calls Out calls Busied Failed No Succ

Mdm Usage Succ Fail Succ Fail Out Dial Answer Pct.

1/0 37% 98 4 0 0 0 0 0 96%

1/1 38% 98 2 0 0 0 0 0 98%

* 1/2 2% 3 99 0 0 0 0 0 1%

.

.

.

Router# configure terminal

Router(config)# line 3

Router(config)# modem shutdown

Router(config)# modem bad

Router(config)# exit

Router# show modem

Inc calls Out calls Busied Failed No Succ

Mdm Usage Succ Fail Succ Fail Out Dial Answer Pct.

1/0 37% 98 4 0 0 0 0 0 96%

1/1 38% 98 2 0 0 0 0 0 98%

B 1/2 2% 3 99 0 0 0 0 0 1%

.

Busying Out a Modem Card

To busy out a modem card in a Cisco access server, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

port

Specifies the line number, by specifying the shelf, slot, and port numbers; you must type in the slashes. This command also begins line configuration mode.

Step 2

busyout command to busy out the modem. The command disables the modem associated with line shelf/slot/port from dialing and answering calls.You need not specify a shelf/slot/port number again in this command.

Step 3

command.

Step 4

Exits line configuration mode and returns to global configuration mode.

Step 5

.

Step 6

Exits global configuration mode and returns to privileged EXEC mode.

Step 7

From privileged EXEC mode, verifies that the line is busied out. If there are active calls, the software waits until the call terminates before the line is busied out.

command can busy out and eventually terminate all 72 ports on the Cisco AS5800 modem card.

Monitoring Resources on Cisco High-End Access Servers

The following tasks enable you to monitor the network access server (NAS) health conditions at the DS0 level, PRI bearer channel level, and modem level. Performing these tasks will benefit network operation with improved visibility into the line status for the NAS for comprehensive health monitoring and notification capability, and improved troubleshooting and diagnostics for large-scale dial networks.

Perform the following tasks to monitor resource availability on the Cisco high-end access servers:

- Enabling DS0 Busyout Traps—DS0 busyout traps are generated when there is a request to busy out a DS0, when there is a request to take a DS0 out of busyout mode, or when busyout completes and the DS0 is out-of-service. DS0 busyout traps are generated at the DS0 level for both CAS and ISDN configured lines. This feature is enabled and disabled through use of the CLI and MIBs. DS0 busyout traps are disabled by default and are supported on Cisco AS5300, Cisco AS5400, and Cisco AS5800 universal access servers.

- Enabling ISDN PRI Requested Channel Not Available Traps—ISDN PRI channel not available traps are generated when a requested DS0 channel is not available, or when there is no modem available to take the incoming call. This feature is available only for ISDN PRI interfaces. This feature is enabled and disabled through use of CLI for ISDN traps and the CISCO-ISDN-MIB. ISDN PRI channel not available traps are disabled by default and are supported on the Cisco AS5300, Cisco AS5400, and Cisco AS5800.

- Enabling Modem Health Traps—Modem health traps are generated when a modem port is bad, disabled, reflashed, or shut down, or when there is a request to busy out the modem. This feature is enabled and disabled through use of CLI and the CISCO-MODEM-MGMT-MIB. Modem health traps are disabled by default and are supported on the Cisco AS5300, Cisco AS5400, and Cisco AS5800.

- Enabling DS1 Loopback Traps—DS1 loopback traps are generated when a DS1 line goes into loopback mode. This feature is enabled and disabled by CLI and the CISCO-POP-MGMT-MIB. DS1 loopback traps are disabled by default and are supported on the Cisco AS5300 and Cisco AS5400 only.

The CISCO-POP-MGMT-MIB supplies the DS0 busyout traps and the DS1 loopback traps. The CISCO-MODEM-MGMT-MIB supplies additional modem health traps when the modem port becomes non-functional. The CISCO-ISDN-MIB supplies additional traps for ISDN PRI channel not available.

http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.

See the sections “Verifying Enabled Traps” and “Troubleshooting the Traps” to verify and troubleshoot configuration. The section “NAS Health Monitoring Example” provides output of a configuration with the NAS health monitoring features enabled.

Enabling DS0 Busyout Traps

commands. Refer to the Cisco IOS Configuration Fundamentals Configuration Guide for more information on these commands.

To generate DS0 busyout traps, use the following command in global configuration mode:

Command

Purpose

Router(config)# snmp-server enable traps ds0-busyout

Generates a trap when there is a request to busy out a DS0 or to indicate when busyout finishes.

Enabling ISDN PRI Requested Channel Not Available Traps

To generate ISDN PRI requested channel not available traps, use the following command in global configuration mode:

Command

Purpose

Router(config)# snmp-server enable traps isdn chan-not-avail

Generates a trap when the NAS rejects an incoming call on an ISDN PRI interface because the channel is not available.

Enabling Modem Health Traps

To generate modem health traps, use the following command in global configuration mode:

Command

Purpose

Router(config)# snmp-server enable traps modem-health

Generates a trap when a modem port is bad, disabled, or prepared for firmware download; when download fails; when placed in loopback mode for maintenance; or when there is a request to busy out the modem.

Enabling DS1 Loopback Traps

To generate DS1 loopback traps, use the following command in global configuration mode:

Command

Purpose

Router(config)# snmp-server enable traps ds1-loopback

Generates a trap when the DS1 line goes into loopback mode.

Verifying Enabled Traps

command. The following output indicates that all the traps are enabled:

Router(config)# show run

snmp-server enable traps ds0-busyout

snmp-server enable traps isdn chan-not-avail

snmp-server enable traps modem-health

snmp-server enable traps ds1-loopback

keyword to display details about the channel state. This feature shows whether the DS0 channels of a particular controller are in idle, in-service, maintenance, or busyout state. This enhancement applies to both CAS and ISDN PRI interfaces and is supported on the Cisco AS5300 and Cisco AS5400 only.

Troubleshooting the Traps

To troubleshoot the traps, turn on the debug switch for SNMP packets by entering the following command in privileged EXEC mode:

Router# debug snmp packets

Check the resulting output to see that the SNMP trap information packet is being sent. The output will vary based on the kind of packet sent or received:

SNMP: Packet received via UDP from 10.5.4.1 on Ethernet0

SNMP: Get-next request, reqid 23584, errstat 0, erridx 0

sysUpTime = NULL TYPE/VALUE

system.1 = NULL TYPE/VALUE

system.6 = NULL TYPE/VALUE

SNMP: Response, reqid 23584, errstat 0, erridx 0

sysUpTime.0 = 2217027

system.1.0 = Cisco Internetwork Operating System Software

system.6.0 =

SNMP: Packet sent via UDP to 10.5.4.1

You can also use trap monitoring and logging tools like snmptrapd, with debugging flags turned on, to monitor output.

NAS Health Monitoring Example

The following is sample configuration output showing all NAS health monitoring traps turned on:

Building configuration...

Current configuration:

! Last configuration change at 12:27:30 pacific Thu May 25 2000

version xx.x

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname router

!

aaa new-model

aaa authentication ppp default group radius

enable password <password>

!

spe 1/0 1/7

firmware location system:/ucode/mica_port_firmware

spe 2/0 2/7

firmware location system:/ucode/mica_port_firmware

!

resource-pool disable

!

clock timezone PDT -8

clock calendar-valid

no modem fast-answer

modem country mica usa

modem link-info poll time 60

modem buffer-size 300

ip subnet-zero

!

isdn switch-type primary-5ess

isdn voice-call-failure 0

!

controller T1 0

framing esf

clock source line primary

linecode b8zs

pri-group timeslots 1-24

!

controller T1 1

framing esf

linecode b8zs

ds0-group 0 timeslots 1-24 type e&m-fgb

cas-custom 0

!

controller T1 2

shutdown

clock source line secondary 2

!

controller T1 3

shutdown

clock source line secondary 3

!

controller T1 4

shutdown

clock source line secondary 4

!

controller T1 5

shutdown

clock source line secondary 5

!

controller T1 6

shutdown

clock source line secondary 6

!

controller T1 7

shutdown

clock source line secondary 7

!

interface Loopback0

ip address 10.5.4.1

!

interface Ethernet0

no ip address

shutdown

!

interface Serial0

no ip address

shutdown

!

interface Serial1

no ip address

shutdown

!

interface Serial2

no ip address

shutdown

!

interface Serial3

no ip address

shutdown

!

interface Serial0:23

no ip address

ip mroute-cache

isdn switch-type primary-5ess

isdn incoming-voice modem

no cdp enable

!

interface FastEthernet0

ip address 10.5.4.1

duplex full

speed auto

no cdp enable

!

interface Group-Async1

ip unnumbered FastEthernet0

encapsulation ppp

ip tcp header-compression passive

no ip mroute-cache

async mode interactive

peer default ip address pool swattest

no fair-queue

ppp authentication chap

ppp multilink

group-range 1 192

!

interface Dialer1

ip unnumbered FastEthernet0

encapsulation ppp

ip tcp header-compression passive

dialer-group 1

peer default ip address pool swattest

pulse-time 0

no cdp enable

!

ip local pool swattest 10.5.4.1

ip default-gateway 10.5.4.1

ip classless

!

dialer-list 1 protocol ip permit

snmp-server engineID local 00000009020000D058890CF0

snmp-server community public RO

snmp-server packetsize 2048

snmp-server enable traps ds0-busyout

snmp-server enable traps isdn chan-not-avail

snmp-server enable traps modem-health

snmp-server enable traps ds1-loopback

snmp-server host 10.5.4.1 public

!

radius-server host 10.5.4.1 auth-port 1645 acct-port 1646

radius-server retransmit 3

radius-server key <password>

!

line con 0

transport input none

line 1 192

autoselect ppp

modem InOut

transport preferred none

transport input all

transport output none

line aux 0

line vty 0 4

end

Configuration Examples for Modem Management

This section provides the following examples:

- NextPort Modem Log Example

- Modem Performance Summary Example

- Modem AT-Mode Example

- Connection Speed Performance Verification Example

.

NextPort Modem Log Example

The following is partial sample output for the Cisco AS5400 with the NextPort Distributed forwarding Card (DFC). This example shows the port history event log for slot 5, port 47:

Router# show port modem log 5/47

Port 5/47 Events Log

Service type: DATA_FAX_MODEM

Service mode: DATA_FAX_MODEM

Session State: IDLE

00:02:23: incoming called number: 35160

Service type: DATA_FAX_MODEM

Service mode: DATA_FAX_MODEM

Session State: IDLE

Service type: DATA_FAX_MODEM

Service mode: DATA_FAX_MODEM

Session State: ACTIVE

00:02:23: Modem State event:

State: Connect

00:02:16: Modem State event:

State: Link

00:02:13: Modem State event:

State: Train Up

00:02:05: Modem State event:

State: EC Negotiating

00:02:05: Modem State event:

State: Steady

00:02:05: Modem Static event:

Connect Protocol : LAP-M

Compression : V.42bis

Connected Standard : V.34+

TX,RX Symbol Rate : 3429, 3429

TX,RX Carrier Frequency : 1959, 1959

TX,RX Trellis Coding : 16/16

Frequency Offset : 0 Hz

Round Trip Delay : 0 msecs

TX,RX Bit Rate : 33600, 33600

Robbed Bit Signalling (RBS) pattern : 0

Digital Pad : None

Digital Pad Compensation : None

4 bytes of link info not formatted : 0x00 0x00 0x00 0x00 0x00

00:02:06:Modem Dynamic event:

Sq Value : 5

Signal Noise Ratio : 40 dB

Receive Level : -12 dBm

Phase Jitter Frequency : 0 Hz

Phase Jitter Level : 2 degrees

Far End Echo Level : -90 dBm

Phase Roll : 0 degrees

Total Retrains : 0

EC Retransmission Count : 0

Characters transmitted, received : 0, 0

Characters received BAD : 0

PPP/SLIP packets transmitted, received : 0, 0

PPP/SLIP packets received (BAD/ABORTED) : 0

EC packets transmitted, received OK : 0, 0

EC packets (Received BAD/ABORTED) : 0

Modem Performance Summary Example

command:

Router# show modem summary

Incoming calls Outgoing calls Busied Failed No Succ

Usage Succ Fail Avail Succ Fail Avail Out Dial Ans Pct.

14% 2489 123 15 0 0 15 0 3 3 95%

Modem AT-Mode Example

The following example shows that modem 1/1 has one open AT directly connected session:

Router# show modem at-mode

Active AT-MODE management sessions:

Modem User's Terminal

1/1 0 cty 0

Connection Speed Performance Verification Example

commands provide performance information that allow you to investigate possible inoperable or corrupt modems or T1/E1 lines. For example, suppose you have an access server that is fully populated with V.34 modems. If you notice that modem 1/0 is getting V.34 connections only 50 percent of the time, whereas all the other modems are getting V.34 connections 80 percent of the time, then modem 1/0 is probably malfunctioning. If you are reading low connection speeds across all the modems, you may have a faulty channelized T1 or ISDN PRI line connection.

argument with the maximum connect speed that you want to display. You can specify from 12,000 to 56,000 bps. If you are interested in viewing a snapshot of lower baud rates, specify a lower connection speed. If you are interested in displaying a snapshot of higher rates, specify a higher connection speed.

The following example displays connection speed information for modems running up to 33,600 bps:

Router# show modem connect-speeds 33600

transmit connect speeds

Mdm 14400 16800 19200 21600 24000 26400 28800 31200 33600 TotCnt

* 0/0 0 0 0 0 0 0 4 4 1 9

* 0/1 2 0 0 0 0 0 3 3 1 9

0/2 2 0 0 0 0 1 2 4 1 10

* 0/3 0 0 0 1 0 0 3 4 1 9

* 0/4 1 0 0 0 0 2 2 1 1 7

* 0/5 0 0 0 0 0 0 4 4 1 9

* 0/6 0 0 0 0 0 1 3 3 1 8

* 0/7 0 0 0 2 0 0 4 3 1 10

* 0/8 2 0 0 0 0 0 3 4 1 10

* 0/9 0 0 0 0 0 0 4 3 0 7

* 0/10 1 0 0 0 0 1 3 2 1 8

* 0/11 0 0 0 0 0 0 4 3 1 8

0/12 1 0 0 0 0 0 4 2 1 8

* 0/13 0 0 0 0 0 0 4 2 1 7

* 0/14 1 0 0 0 0 1 2 2 1 7

* 0/15 0 0 0 0 0 0 4 2 1 7

* 0/16 0 0 0 1 0 0 3 2 1 7

* 0/17 1 0 0 0 0 0 4 2 1 8

* 0/18 1 0 0 0 0 0 3 3 1 8

* 0/19 0 0 0 0 0 0 5 3 1 9

* 0/20 0 0 0 0 0 0 4 2 1 7

* 0/21 1 0 0 0 0 0 4 2 0 7

* 0/22 0 0 0 0 0 0 7 9 1 17

* 0/23 0 0 0 0 0 2 2 3 1 8

* 2/0 0 0 0 1 0 0 3 3 1 8

* 2/1 0 0 0 0 0 0 5 2 1 8

* 2/2 0 0 0 1 0 0 4 1 1 7

* 2/3 1 0 0 0 0 0 4 2 1 8

* 2/4 0 0 0 0 0 0 5 2 1 8

* 2/5 0 0 0 0 0 0 4 3 1 8

* 2/6 0 0 0 0 0 0 3 2 1 6

* 2/7 1 0 0 0 0 1 3 2 0 7

* 2/8 1 0 0 0 0 0 3 2 1 7

* 2/9 0 0 0 0 0 1 3 2 1 7

* 2/10 2 0 0 0 0 2 1 0 1 6

* 2/11 0 0 0 1 0 1 3 5 1 11

* 2/12 0 0 0 0 0 0 5 2 1 8

* 2/13 1 0 0 0 0 0 5 0 1 7

* 2/14 1 0 0 0 0 0 3 3 1 8

* 2/15 1 0 0 0 0 1 2 3 1 8

* 2/16 0 0 0 0 0 0 4 3 1 8

* 2/17 0 0 0 0 0 0 5 11 0 16

* 2/18 0 0 0 1 0 1 1 2 1 6

* 2/19 0 0 0 0 0 0 2 3 1 6

* 2/20 1 0 0 0 0 2 3 9 1 16

* 2/21 1 0 0 0 0 0 4 1 1 7

* 2/22 0 0 0 1 0 0 2 3 1 7

* 2/23 0 0 0 0 0 1 3 3 1 8

Tot 23 0 0 9 0 18 165 141 44 400

Tot % 5 0 0 2 0 4 41 35 11

receive connect speeds

Mdm 14400 16800 19200 21600 24000 26400 28800 31200 33600 TotCnt

* 0/0 0 0 0 0 0 4 1 3 1 9

* 0/1 2 0 0 0 0 3 1 2 1 9

0/2 2 0 0 0 0 3 1 3 1 10

* 0/3 0 0 0 1 0 3 4 0 1 9

* 0/4 1 0 0 0 0 4 0 1 1 7

* 0/5 0 0 0 0 0 4 3 1 1 9

* 0/6 0 0 0 0 0 4 0 3 1 8

* 0/7 0 0 0 2 0 4 1 2 1 10

* 0/8 2 0 0 0 0 3 0 5 0 10

* 0/9 0 0 0 0 0 4 2 0 1 7

* 0/10 1 0 0 0 0 4 0 2 1 8

* 0/11 0 0 0 0 0 4 0 3 1 8

0/12 1 0 0 0 0 2 2 2 1 8

* 0/13 0 0 0 0 0 4 1 1 1 7

* 0/14 1 0 0 0 0 2 3 0 1 7

* 0/15 0 0 0 0 0 4 1 1 1 7

* 0/16 0 0 0 1 0 3 2 0 1 7

* 0/17 1 0 0 0 0 4 1 1 1 8

* 0/18 1 0 0 0 0 3 2 1 1 8

* 0/19 0 0 0 0 0 5 1 2 1 9

* 0/20 0 0 0 0 0 4 0 3 0 7

* 0/21 1 0 0 0 0 4 0 1 1 7

* 0/22 0 0 0 0 0 6 6 4 1 17

* 0/23 0 0 0 0 0 4 2 1 1 8

* 2/0 0 0 0 1 0 3 1 2 1 8

* 2/1 0 0 0 0 0 3 3 1 1 8

* 2/2 0 0 0 1 0 4 0 1 1 7

* 2/3 1 0 0 0 0 3 2 1 1 8

* 2/4 0 0 0 0 0 4 2 1 1 8

* 2/5 0 0 0 0 0 4 1 2 1 8

* 2/6 0 0 0 0 0 3 0 3 0 6

* 2/7 1 0 0 0 1 2 2 0 1 7

* 2/8 1 0 0 0 0 3 0 2 1 7

* 2/9 0 0 0 0 0 4 1 1 1 7

* 2/10 2 0 0 0 0 3 0 0 1 6

* 2/11 0 0 0 1 0 3 1 5 1 11

* 2/12 0 0 0 0 0 4 3 0 1 8

* 2/13 1 0 0 0 0 2 3 0 1 7

* 2/14 1 0 0 0 0 3 2 1 1 8

* 2/15 1 0 0 0 0 3 0 3 1 8

* 2/16 0 0 0 0 0 4 0 4 0 8

* 2/17 0 0 0 0 0 5 2 8 1 16

* 2/18 0 0 1 0 0 2 1 1 1 6

* 2/19 0 0 0 0 0 2 2 1 1 6

* 2/20 1 0 0 0 0 4 2 8 1 16

* 2/21 1 0 0 0 0 4 0 1 1 7

* 2/22 0 0 1 0 0 2 0 3 1 7

* 2/23 0 0 0 0 0 4 2 1 1 8

Tot 23 0 2 7 1 167 64 92 44 400

Tot % 5 0 0 1 0 41 16 23 11

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001–2009 Cisco Systems, Inc. All rights reserved.

1- and 2-Port V.90 Modem WICs for Cisco 2600 and Cisco 3600 Series Multiservice Platforms

Feature History

Release

Description

12.2(2)XB

This feature was introduced.

12.2(8)T

This feature was integrated into the Cisco IOS Release 12.2(8)T.

The 1- and 2-port V.90 modem WAN interface cards (WICs) for Cisco 2600 and 3600 series multiservice platforms provide low-density integrated modems to satisfy the market demand for remote management, dial-backup, and low-density remote-access servers (RAS).

This document describes the 1-port and 2-port V.90 modem WIC feature and contains the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Configuration Tasks

- Command Reference

- Glossary

Feature Overview

Three applications are available for the V.90 modem WIC on the Cisco 2600 and Cisco 3600 series multiservice platforms:

Remote Router Management and Out-of-Band Access

In this mode, the modem WIC is used as a dial-in modem for remote terminal access to the router’s command-line interface (CLI) for configuration, troubleshooting, and monitoring. The modem WIC acts similar to a modem that is connected to the AUX port of a router, but the integrated nature of the modem WIC greatly decreases customer configuration time and deployment and sustaining costs. Typically, the 1-port modem WIC is used for this application. Connection speeds of up to 33.6 kbps are possible.

Asynchronous Dial-on-Demand Routing and Dial-Backup

In this mode, the V.90 modem WIC transports network traffic. When ISDN service is not available and the traffic load does not justify a leased-line or Frame Relay connection, asynchronous dial-on-demand routing (DDR) is often the only choice for making a WAN connection. Even at sites that do have leased-line or Frame Relay connection, asynchronous DDR can increase bandwidth during sustained traffic load. In addition, when the primary leased-line or Frame Relay link is down during an outage, asynchronous dial-backup provides a secondary way to make the WAN connection. Both the 1-port and 2-port versions of the V.90 modem WIC can be used for this application.

:

Two ports on one modem WIC (or even three or more ports spanning multiple modem WIC cards) can be combined using Multilink PPP (MLP) to increase connection speeds in a scalar manner. Each connection is capable of V.90 speeds (up to 56 kbps) when connecting to a digital V.90 server modem.

:

http://www.cisco.com/warp/public/131/mppp-ddr.html

Low-Density Analog RAS Access

In this application, the V.90 modem WIC enables the platform to provide the services of a typical small remote access server (RAS). One service allows remote users to dial in and gain access to resources on the LAN (or even across the WAN). The analog modems in the modem WIC allow dial-in connection speeds of up to 33.6 kbps, but MLP can bind multiple links together and increase the throughput.

Another service allows PCs (running Cisco DialOut Utility) on the LAN to use the modems for dial-out. Users can connect to other modems (bulletin boards, AOL, ISPs, and so on) or fax machines. The modem WIC allows dial-out connection speeds of up to 56 kbps when dialing a digital V.90 server modem or up to 33.6 kbps when dialing another analog modem. Fax calls connect at up to 14.4 kbps.

Typical RAS deployments with the V.90 modem WIC use the 2-port modem version. With enough slots, the V.90 modem WIC can be used to scale to up to 24 modems in a Cisco 3660 multiservice platform.

There is no limit for lines in the MLP bundle with WICs and population of WICs on any Cisco 2600 series or Cisco 3600 series multiservices platforms.

Benefits

The 1-port and 2-port V.90 modem WIC feature provides the following benefits:

- Integrated solution for ease of deployment

- Improved remote management

- Cost-effective alternative to leased lines or ISDN

Restrictions

Platform Memory Requirements

- Cisco 2600 ip —8M Flash, 32M DRAMM.

- Cisco 3620 ip plus—16M Flash, 48M DRAMM.

- Cisco 3620 enterprise—16M Flash, 64M DRAMM.

- Cisco 3640 ip plus—16M Flash, 64M DRAMM.

- Cisco 3640 enterprise—16M Flash, 64M DRAMM.

- Cisco 3660 ip plus—16M Flash and 64M DRAMM.

- Cisco 3660 enterprise—16M Flash and 64M DRAMM.

Caution Ensure that the RJ-11/CA11 telephone cable is disconnected from the modem WIC before installing or removing the modem WIC from the router. The phone jack can have DC potential (up to 56.5 VDC) and can have ring signal (up to 150 VAC) in the United States.

Caution Ensure that the router is powered OFF before installing or removing the modem WIC from the router. The modem WICs do not support online insertion and removal (hot-swap).

. For troubleshooting and verification, use only the following commands:

Related Features and Technologies

For general and specific information on wide-area networking, see the following documents:

- Cisco IOS Wide-Area Networking Configuration Guide, Release 12.2 http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fwan_c/index.htm

- Cisco IOS Wide-Area Networking Command Reference, Release 12.2 http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fwan_r/index.htm

Related Documents

- WAN Interface Cards Hardware Installation Guide

http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/cis3600/wan_mod/index.htm

- Modem-Router Connection Guide

http://www.cisco.com/warp/public/76/9.html

- Cisco 3600-Series Router Configurations

http://www.cisco.com/warp/public/793/access_dial/3600_index.html

- Cisco IOS Dial Services Quick Configuration Guide

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121sup/121dsqcg/index.htm

Supported Platforms

The following Cisco multiservice platforms are supported for the Cisco IOS Release 12.2(8)T:

- Cisco 2600 series

- Cisco 3600 series

Supported Standards, MIBs, and RFCs

Standards

No new or modified standards are supported by this feature.

MIBs

No new or modified MIBs are supported by this feature.

To obtain lists of MIBs supported by platform and Cisco IOS release and to download MIB modules, go to the Cisco MIB web site on Cisco Connection Online (CCO) at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.

RFCs

No new or modified RFCs are supported by this feature.

Configuration Tasks

Configuration tasks required for setting up the modem WIC for proper operation are:

- Asynchronous Interface Configuration

- Line Configuration

Asynchronous Interface Configuration

To configure the asynchronous interface on the V.90 modem WIC, use the following commands, starting in global configuration mode:

Command

Purpose

Step 1

Enters the interface configuration mode for the asynchronous serial interface. Enter the number of the interface you want to configure.

Step 2

Conserves IP addresses by configuring the asynchronous interface as unnumbered, and assigns the IP address of the interface type that you want to leverage.

Step 3

Sets the encapsulation protocol for Point-to-Point Protocol (PPP).

Step 4

Specifies that dial-on-demand routing (DDR) is to be supported. This command specifies that chat scripts will be used on asynchronous interfaces. The parity keywords do not apply to asynchronous interfaces.

Step 5

Enters the dialer string (telephone) number.

Step 6

command. Acceptable values are within the range from 1 to 10.

Step 7

Configures interactive mode on the asynchronous interface.

Step 8

Example:

Router(config)# interface asyn 33

Router(config-if)# ip unnumbered f0/0

Router(config-if)# encapsulation ppp

Router(config-if)# dialer in-band

Router(config-if)# dialer string 14085551234

Router(config-if)# dialer-group 1

Router(config-if)# asyn mode interactive

Router(config-if)# peer default ip address pool pool123

Note pool123 is a name chosen for the pool used for defining the range of IP addresses for remote clients.

Line Configuration

To configure the line on the V.90 modem WIC, use the following commands, starting in global configuration mode:

Command

Purpose

Step 1

Enters the interface configuration mode for the asynchronous serial interface. Enter the number of the interface you want to configure.

Step 2

Enters interface mode line configuration submode.

Note The number entered here must be the same as the number entered for the asynchronous serial interface when the interface configuration mode was first entered.

Step 3

Configures the line for both incoming and outgoing calls.

Step 4

is recommended.

Step 5

is recommended.

Example:

Router(config-if)# line 33

Router(config-line)# modem inout

Router(config-line)# autoselect ppp

Router(config-line)# transport input all

Alternative Configurations for the Modem WIC

Configuring the Group Asynchronous Interface

interface Group-Async1

ip address negotiated

no ip directed-broadcast

encapsulation ppp

dialer in-band

dialer idle-timeout 512 either

dialer-group 1

async default routing

async mode dedicated

no peer default ip address

no fair-queue

no cdp enable

ppp authentication chap

group-range 33 34

hold-queue 10 in

Configuring the Dialer List

dialer-list 1 protocol ip permit

Configuring the Line

line 97 112

exec-timeout 0 0

autoselect ppp

script dialer dial

login local

modem InOut

transport input all

stopbits 1

flowcontrol hardware

Configuring the Dialer Interface

interface Dialer1

ip address 199.0.1.2 255.255.255.0

no ip redirects

no ip directed-broadcast

no ip proxy-arp

encapsulation ppp

load-interval 30

dialer remote-name d1

dialer pool 1

dialer idle-timeout 7200 either

dialer-group 1

no fair-queue

pulse-time 0

no cdp enable

Configuring for Asynchronous Dial Backup

The following example shows an asynchronous dial backup configuration:

interface Serial2/0

ip address 70.1.1.2 255.255.255.0

backup delay 15 15

backup interface as33

interface Async33

ip address 51.1.1.2 255.255.255.0

encapsulation ppp

dialer in-band

dialer map ip 51.1.1.1 name m1_2621_33 modem-script cisco-default 101

dialer-group 1

ppp authentication chap

async mode interactive

!

router eigrp 100

redistribute static

network 10.0.0.0

network 70.0.0.0

!

ip route 10.0.0.0 255.0.0.0 51.1.1.2 180

!/very important/

line 33

autoselect ppp

modem InOut

flowcontrol hardware

transport input all

In this example, the interface S2/0 is configured as a primary link. Configuring the route through the backup interface (the V.90 modem WIC in this case) is very important. 10.0.0.0 in the IP route indicates the network number of the remote end. Thus, all packets for the destination IP are routed through the backup link if the primary link goes down. The 180 in the route command indicates the cost of the route taken (It should be more than the cost of the primary route). This avoids the packets taking the backup link when the primary link is up.

Verifying the V.90 Modem WIC Configuration

Shown below are a few of the many commands that can be used to verify, monitor, and troubleshoot the V.90 modem WIC. Other commands are described in the Related Documents.

The show interface async [tty-number] command shows the state of the specified asynchronous interface.

Example:

3640-Router# show interfaces asynch 1

Async 1 is up, line protocol is up

Hardware is Conexant modem

Internet address is 1.0.0.1, subnet mask is 255.0.0.0

MTU 1500 bytes, BW 9 Kbit, DLY 100000 usec, rely 255/255, load 56/255

Encapsulation ppp, keepalive set (0 sec)

Last input 0:00:03, output 0:00:03, output hang never

Last clearing of "show interface" counters never

Output queue 0/3, 2 drops; input queue 0/0, 0 drops

Five minute input rate 0 bits/sec, 1 packets/sec

Five minute output rate 2000 bits/sec, 1 packets/sec

273 packets input, 13925 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

221 packets output, 41376 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets, 0 restarts

0 carrier transitions

The show modem [slot/port | group number] command shows various performance statistics for a modem or group of modems.

Example:

3640-Router# show modem 1/0

Mdm Typ Status Tx/Rx G Duration TX RX RTS CTS DSR DCD DTR

1/0 V34 Idle 33600 /33600 0 00:02:41 - - x x - x

Modem 1/0 [line 33], Async33, TTY33

SCM firmware P2109-V90

Modem config:Incoming and Outgoing

Protocol:LAPM, Compression:V42B

Last clearing of "show modem" counters:00:24:52

2 incoming complete

0 incoming failures

0 outgoing complete

1 outgoing failure

Modulation type V34

# of connections 1

Protocol type LAPM

# of connections 1

Transmit Speed Counters:

Connection Speeds 33600

# of connections 1

Receive Speed Counters:

Connection Speeds 33600

# of connections 1

Troubleshooting the V.90 Modem WIC Operation

command, as shown in the following example:

[no] debug modem

This command shows the state of the tty lines.

Example:

00:05:04:TTY1:dropping DTR, hanging up

00:05:04:TTY1:Async Int reset:Dropping DTR

00:05:04:tty1:Modem:HANGUP->(unknown)cpm_modem_interrupt_handler

00:05:05:TTY1:cleanup pending. Delaying DTR

00:05:05:TTY1:cleanup pending. Delaying DTR

00:05:06:TTY1:cleanup pending. Delaying DTR

00:05:06:TTY1:cleanup pending. Delaying DTR

00:05:06:%LINK-5-CHANGED:Interface Async1, changed state to reset

00:05:07:TTY1:cleanup pending. Delaying DTR

00:05:07:TTY1:cleanup pending. Delaying DTR

00:05:07:%LINEPROTO-5-UPDOWN:Line protocol on Interface Async1,

changed state to down

00:05:08:TTY1:cleanup pending. Delaying DTR

00:05:08:TTY1:cleanup pending. Delaying DTR

Command Reference

.

Glossary

—bits per second data rate of an asynchronous interface.

—dial-on-demand routing. Also known as direct data routing or dial-up routing (PPP or IP).

—Dynamic Random Access Memory Module.

—A single 64 kbps channel of a T1 span.

—digital signal processor.

—digital signal processing module—voice module card.

—Internet Operating System.

—Integrated Services Digital Network.

—network module.

—modular access router.

—Multilink PPP.

—Online insertion and removal (hot swap).

—Plain old telephone service.

—Point-to-Point Protocol.

—Public Switched Telephone Network.

—remote access server.

—time-division multiplexing. Also used to describe a single channel on a TDM bus.

—voice feature card.

—voice interface card.

—WAN interface card.

Note For a list of other internetworking terms, see the Internetworking Terms and Acronyms document available on the Documentation CD-ROM and Cisco Connection Online (CCO) at the following URL: http://www.cisco.com/univercd/cc/td/doc/cisintwk/ita/index.htm.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2001-2008 Cisco Systems, Inc. All rights reserved.

Call Tracker show Commands Extensions

Feature History

Release

Modification

12.2(11)T

This feature was introduced.

This document describes the Asynchronous Line Monitoring feature feature in Cisco IOS Release 12.2(11)T and includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Prerequisites

- Configuration Tasks

- Configuration Examples

- Command Reference

- Glossary

Feature Overview

commands provided a simple way to examine the Call Tracker active table and Call Tracker history table in chronological order. The extensions to these commands available in Cisco IOS Release 12.2(11)T allow the command output to be reverse collated (output from most recent to least recent) or to be filtered by call category or service type. Historical data for disconnected call sessions can be filtered by subsystem type.

Benefits

commands. Streamlined command output simplifies troubleshooting, especially for newer platforms where the number of ports is in the several hundreds, or even thousands.

Supported Platforms

- Cisco AS5300

- Cisco AS5350

- Cisco AS5400

- Cisco AS5800

- Cisco AS5850

Determining Platform Support Through Cisco Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Cisco Feature Navigator is a web-based tool that enables you to determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.

Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:

Availability of Cisco IOS Software Images

Platform support for particular Cisco IOS software releases is dependent on the availability of the software images for those platforms. Software images for some platforms may be deferred, delayed, or changed without prior notice. For updated information about platform support and availability of software images for each Cisco IOS software release, refer to the online release notes or, if supported, Cisco Feature Navigator.

Supported Standards, MIBs, and RFCs

Standards

No new or modified standards are supported by this feature.

MIBs

No new or modified MIBs are supported by this feature.

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

RFCs

No new or modified RFCs are supported by this feature.

Prerequisites

.

Configuration Tasks

None

Configuration Examples

None

Command Reference

.

- show call calltracker active

- show call calltracker history

Glossary

—Challenge Handshake Authentication Protocol. Security feature supported on lines using PPP encapsulation that prevents unauthorized access. CHAP does not itself prevent unauthorized access, but merely identifies the remote end. The router or access server then determines whether that user is allowed access.

—digital signal processor. A DSP segments the voice signal into frames and stores them in voice packets.

—network access server. Cisco platform (or collection of platforms, such as an AccessPath system) that interfaces between the packet world (for example, the Internet) and the circuit world (for example, the Public Switched Telephone Network).

—Virtual Private Network. Enables IP traffic to travel securely over a public TCP/IP network by encrypting all traffic from one network to another. A VPN uses tunneling to encrypt all information at the IP level.Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001–2009 Cisco Systems, Inc. All rights reserved.

Cisco NM-8AM-V2 and NM-16AM-V2 Analog Modem Network Modules with V.92

The Cisco NM-8AM-V2 and NM-16AM-V2 Analog Modem Network Modules with V.92 serve as integrated analog modem network modules (NMs) for the modular access routers (MARS) family of routers. These network modules terminate either 8 or 16 analog modem connections through POTS interfaces.

For information on new features and Cisco IOS commands supported by software for the Cisco NM-8AM-V2 and NM-16AM-V2 network modules, see the “Additional References” section.

Feature History for Cisco NM-8AM-V2 and NM-16AM-V2 Network Modules

Release

Modification

12.3(4)XD

This feature was introduced.

12.3(7)T

This feature was integrated into the Cisco IOS Release 12.3(7)T on the Cisco 2600XM series and Cisco 3700 series routers.

Finding Support Information for Platforms and Cisco IOS Software Images

at the login dialog box and follow the instructions that appear.

Contents

- Information About Cisco NM-8AM-V2 and NM-16AM-V2 Network Modules

- How to Configure the Cisco NM-8AM-V2 and NM-16AM-V2 Network Modules

- Configuration Examples for Cisco NM-8AM-V2 and NM-16AM-V2 Network Modules

- Additional References

- Command Reference

- Glossary

Information About Cisco NM-8AM-V2 and NM-16AM-V2 Network Modules

This section contains information that you need to use the Cisco NM-8AM-V2 and NM-16AM-V2 network modules.

- Overview

- Key Features and Benefits

- Chat Script

Overview

Two new analog modem network modules, the Cisco NM-8AM-V2 and NM-16AM-V2 network modules, support basic telephone service connections on Cisco 2600XM series routers, Cisco 3600 series, and Cisco 3700 series. These network modules allow the following:

- Standard telephone connections on RJ-11 connectors

- Up to 16 remote analog modem users to connect to a Cisco 2600XM series

- Up to 32 remote analog modem users to connect to a Cisco 3725

- Up to 64 remote analog modem users to connect to a Cisco 3745

- Up to 96 remote analog modem users to connect to a Cisco 3660

Combined with the differentiated services delivered through Cisco IOS software, users of Cisco 2600XM series, Cisco 3600 series, and Cisco 3700 series routers have best-of-breed scalability, flexibility, and investment protection, all in cost-effective, multifunctional platforms.

Key Features and Benefits

The Cisco NM-8AM-V2 and NM-16AM-V2 network modules provide several new features and benefits.

- 8 or 16 internal V.34/V.42bis/V.44/V.90/V.92 analog modems per network module

- Up to 56-kbps data download and 14.4-kbps fax communication

- V.92 Quick Connect and Modem-on-Hold features

- Simple Network Management Protocol (SNMP) based tools with centrally-managed modem capabilities used to manage the rest of the network (such as CiscoView and Cisco Works 2000)

- Support for a broad range of dial-in features with Cisco IOS dial access software

- Software upgradable modem firmware to support possible future changes

- Support for all traditional Cisco IOS asynchronous encapsulations and WAN services

- Modem AT command interface

- Managed modem support via Cisco IOS CLI commands and Cisco Modem Management MIB

- Support for online insertion and removal (OIR) on Cisco 3660 and Cisco 3745 routers

- Compatible with approved Dialout Client applications

These features enable a wide variety of dial-in clients to use the applications and facilities of the branch office network.

- Virtual private network (VPN) support—This feature allows for cost-effective connections for a geographically dispersed user base. It can reduce access cost support and allow remote users straightforward access to their office LAN through a local Internet service provider (ISP), while maintaining a high degree of end-to-end security.

- Robust security features—Utilizing TACACS+, Challenge Handshake Authentication Protocol/Password Authentication Protocol (CHAP/PAP), Triple Data Encryption Standard (3-DES) encryption, and the built-in firewall capabilities of Cisco IOS software allows secure access for a wide variety of remote users to sensitive company data.

Network Management

- CiscoWorks—Allows centralized management of multiple Cisco 2600XM, Cisco 3600, and Cisco 3700 routers.

- In-band and out-of-band management via TCP/IP and SNMP, including MIB II and other extensions, over TCP/IP.

- TCP/IP addresses can be assigned via DHCP, per user, or via an internal address pool, or they can be selected remotely.

- Maintains a detailed activity log for accounting, billing, and troubleshooting.

- Ability to download image and configuration across routers.

Security

- Username, password, and dial-back security

- Multilevel administration password support

- CHAP and PAP support

- Centralized authentication via AAA

- IP device and network filtering

- AppleTalk zone and device filtering

Modem Management

The Cisco 2600XM series, Cisco 3600 series, and Cisco 3700 series routers ship with general network management capabilities.

Note • The analog modem network module is being submitted for approval worldwide, but because of specific in-country approval processes, approval dates vary. For the latest availability status, please check online at http://www.cisco.com.

Note • The analog modem network module is being submitted for approval worldwide, but because of specific in-country approval processes, approval dates vary. For the latest availability status, please check online at http://www.cisco.com.

- For more information on the AT command set used by these modems, please check online at http://www.cisco.com .

Chat Script

The Cisco NM-8AM-V2 and NM-16AM-V2 network modules support chat script like other Cisco modem modules. There is no need to put a factory reset parameter in the chat script because this will interfere with the modem settings configured internally by the Cisco NM-xAM-V2 firmware. If a factory reset parameter is included, the parameter may interfere with how the connection speed is collected and the modem may be unreliable in any reports on the speed.

When using the AT&F reset parameter in a chat-script with Cisco NM-8AM-V2 and NM-16AM-V2 network modules, the reset parameter should be used in conjunction with the connect string setting. For example:

AT&F\\v1s0=1

This setting gives a factory reset, a long connect string, and answers after one ring. For more information, refer to the documentation at:

How to Configure the Cisco NM-8AM-V2 and NM-16AM-V2 Network Modules

To configure the Cisco NM-8AM-V2 and NM-16AM-V2 network modules, perform the tasks listed below:

- Configuring the Modems for the Country of Deployment (required)

- Verifying the Modem Configuration (optional)

Configuring the Modems for the Country of Deployment

The Cisco NM-8AM-V2 and NM-16AM-V2 network modules are designed to customize their settings to the country in which they are deployed. To configure a modem for the country of deployment, perform this configuration task.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Sets the modem firmware to use settings for the country of deployment.

Step 4

Router(config)# end

Exits global configuration mode and returns to privileged EXEC mode.

Verifying the Modem Configuration

Perform the following tasks to verify the modem configuration.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# show modem version

Displays the modem firmware version and datapump version.

Step 3

debug modem

Router# debug modem

Displays the modem events and state transitions.

Step 4

Router# show modem version

Displays the modem firmware version, the datapump version, and the firmware log.

Step 5

exit

Exits privileged EXEC mode.

Troubleshooting Tips

Use the following debug commands to troubleshoot the modem:

- debug async state

- debug dialer

- debug dialer forwarding

- debug dialer map

- debug dialer packets

- debug modem

- debug ppp events

- debug ppp forwarding

- debug ppp negotiation

- debug ppp packet

commands to troubleshoot the Cisco NM-8AM-V2 and NM-16AM-V2 network modules.

Router# debug modem

Router# debug dialer

Router# ping 10.1.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:

*Jul 27 05:40:24.524 EST: As33 DDR: place call

*Jul 27 05:40:24.524 EST: As33 DDR: Dialing cause ip (s=10.1.1.1, d=10.1.1.1)

*Jul 27 05:40:24.524 EST: As33 DDR: Attempting to dial 102

*Jul 27 05:40:24.524 EST: CHAT33: Attempting async line dialer script

*Jul 27 05:40:24.524 EST: CHAT33: Dialing using Modem script: dial & System script: none

*Jul 27 05:40:24.524 EST: CHAT33: process started

*Jul 27 05:40:24.524 EST: CHAT33: Asserting DTR

*Jul 27 05:40:24.524 EST: CHAT33: Chat script dial started

*Jul 27 05:40:24.524 EST: Modem 1/0 ACF: CMD DTR set high

*Jul 27 05:40:24.888 EST: Modem 1/0 ACF: Event: Hook state: Off Hook Dialing.

*Jul 27 05:40:24.888 EST: Modem 1/0 ACF: State: Dialing....

*Jul 27 05:40:45.960 EST: Modem 1/0 ACF: Event: CONNECT V34/LAPM/V42B/33600:TX/33600:RX

*Jul 27 05:40:45.960 EST: Modem 1/0 ACF: State: Connected

*Jul 27 05:40:45.972 EST: CHAT33: Chat script dial finished, status = Success

*Jul 27 05:40:45.972 EST: TTY33: no timer type 1 to destroy

*Jul 27 05:40:45.972 EST: TTY33: no timer type 0 to destroy

*Jul 27 05:40:45.972 EST: TTY33: no timer type 2 to destroy

*Jul 27 05:40:45.972 EST: Modem 1/0 ACF: CMD PPP mode active

*Jul 27 05:40:47.972 EST: %LINK-3-UPDOWN: Interface Async33, changed state to up

*Jul 27 05:40:47.972 EST: As33 DDR: Dialer statechange to up

*Jul 27 05:40:47.972 EST: As33 DDR: Dialer call has been placed

*Jul 27 05:40:47.972 EST: Modem 1/0 ACF: CMD PPP escape maps set: TX map=00000000 RX map=FFFFFFFF

*Jul 27 05:40:48.112 EST: Modem 1/0 ACF: CMD PPP escape maps set: TX map=00000000 RX map=000A0000

*Jul 27 05:40:48.212 EST: As33 DDR: dialer protocol up

*Jul 27 05:40:48.972 EST: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async33, changed state to up

Configuration Examples for Cisco NM-8AM-V2 and NM-16AM-V2 Network Modules

Example of the modem country smart_acf Command

command:

Router# config terminal

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)# modem country smart_acf usa

Router(config)# end

Additional References

The following sections provide references related to Cisco NM-8AM-V2 and NM-16AM-V2 network modules.

Related Documents

Related Topic

Document Title

AT Commands

NM-8AM or NM-16AM Analog Modem Module Configuration

Data Sheet on Network Modules

Standards

Standards

Title

No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.

MIBs

MIBs

MIBs Link

No new or modified MIBs are supported by this feature, and support for existing MIBs has not been modified by this feature.

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

RFCs

RFCs

Title

No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.

Technical Assistance

Description

Link

Technical Assistance Center (TAC) home page, containing 30,000 pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.

Command Reference

.

- modem country smart_acf

Glossary

DHCP—Dynamic Host Configuration Protocol.

MARS— modular access routers family of routers.

Note Refer to Internetworking Terms and Acronyms for terms not included in this glossary.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2001-2008 Cisco Systems, Inc. All rights reserved.

MICA and NextPort Modem Tech-Support Command Additions

Feature History

Release

Modification

12.1(13)

(for the Cisco AS5350, AS5400, AS5800, and AS5850 access servers) were introduced.

12.2(11)T

The commands were migrated to Cisco IOS Release 12.2(11)T.

This document describes the Asynchronous Line Monitoring feature and includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Configuration Tasks

- Configuration Examples

- Command Reference

Feature Overview

commands allow customers to collect an extensive report detailing modem functionality by entering a single command.

Benefits

command to his report. Development engineers can then have a consistent output for reference when troubleshooting problems.

Restrictions

commands are available on Cisco AS5300, AS5350, AS5400, AS5800, and AS5850 platforms that support the modem ISDN channel aggregation (MICA technologies) and NextPort service processing element (SPE) modems.

Related Documents

For more information about managing the Cisco MICA and SPE modems, refer to the following documents:

- Cisco IOS Dial Technologies Command Reference , Release 12.2

- Cisco IOS Dial Technologies Configuration Guide , Release 12.2. Refer to the chapter “Configuring and Managing Integrated Modems” in the part “Modem and Dial Shelf Configuration and Management.”

Supported Platforms

- Cisco AS5300

- Cisco AS5350

- Cisco AS5400

- Cisco AS5800

- Cisco AS5850

Determining Platform Support Through Cisco Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Cisco Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.

.

Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:

Supported Standards, MIBs, and RFCs

Standards

None

MIBs

None

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

RFCs

None

Configuration Tasks

No configuration is required to create a modem functionality report. The tasks to start the modem reports are described in the following sections:

- Using the show tech-support Modem EXEC Commands

- Creating a Modem Report

Using the show tech-support Modem EXEC Commands

To start the modem and SPE reports, use the following EXEC commands:

Command

Purpose

Runs a basic list of modem reports for the Cisco AS5300 and AS5800.

Runs a detailed list of modem reports for the Cisco AS5300 and AS5800.

Runs a basic list of modem reports for the Cisco AS5350, AS5400, AS5800, and AS5850.

Runs a detailed list of modem reports for the Cisco AS5350, AS5400, AS5800, and AS5850.

Creating a Modem Report

To create a modem functionality report for MICA and SPE modems, use the following EXEC commands:

- To run a basic modem functionality report, enter the show tech-support modem (MICA modems on a Cisco AS5300 or AS5800) or show tech-support spe commands (SPE modems on Cisco AS5350, AS5400, AS5800, and AS5850) at the privileged EXEC prompt. Table 1 lists the commands that are run by this command, in the order run.

- To run the more detailed modem functionality report, enter the show tech-support modem detail (MICA modems on a Cisco AS5300 or AS5800) or show tech-support spe detail command (SPE modems on Cisco AS5350, AS5400, AS5800, and AS5850) at the privileged EXEC prompt. Table 1 lists the commands that are run by this command, in the order run.

Table 1 Commands Run by show tech-support modem and show tech-support spe Commands

Commands run by the show tech-support spe command:

Additional commands run by the

show tech-support modem detail command:

Additional commands run by the

show tech-support spe detail command:

Configuration Examples

commands are the successive output of many commands. The reports take some time to run and, when captured in a buffer, can be over 100 pages in length. A truncated example is provided in this section to show the extent of the information provided by these reports; however, providing a sample report for each of these commands would take too many pages to provide.

command on a Cisco AS5300:

Router# show tech-support modem

------------------ show version ------------------

Cisco Internetwork Operating System Software

.

.

.

ROM: System Bootstrap, Version xx.xx, RELEASE SOFTWARE (xxx)

BOOTLDR: 5300 Software (C5300-BOOT-M), Version xx.xx, RELEASE SOFTWARE (xxx)

Router uptime is 36 minutes

System returned to ROM by reload at 09:40:14 UTC Thu May 15 1997

System image file is "tftp://...”

cisco AS5300 (R4K) processor (revision A.14) with 65536K/16384K bytes of memory.

Processor board ID 05433558

R4700 CPU at 150Mhz, Implementation 33, Rev 1.0, 512KB L2 Cache

Channelized E1, Version 1.0.

.

.

.

128 Serial network interface(s)

120 terminal line(s)

4 Channelized E1/PRI port(s)

128K bytes of non-volatile configuration memory.

16384K bytes of processor board System flash (Read/Write)

4096K bytes of processor board Boot flash (Read/Write)

Configuration register is 0x0

------------------ show running-config ------------------

Building configuration...

Current configuration : 37974 bytes

!

version 12.2

.

.

.

hostname ...

!

username ...

.

.

.

spe 1/0 2/9

firmware location system:/ucode/mica_port_firmware

.

.

.

end

------------------ show modem version ------------------

Codes:

d - DSP software download is required for achieving K56flex connections

Modem module Firmware Boot DSP

Mdm Number Rev Rev Rev

1/0 0 2.7.2.0

1/1 0 2.7.2.0

1/2 0 2.7.2.0

1/3 0 2.7.2.0

1/4 0 2.7.2.0

1/5 0 2.7.2.0

1/6 1 2.7.2.0

1/7 1 2.7.2.0

1/8 1 2.7.2.0

1/9 1 2.7.2.0

1/10 1 2.7.2.0

1/11 1 2.7.2.0

1/12 2 2.7.2.0

1/13 2 2.7.2.0

1/14 2 2.7.2.0

1/15 2 2.7.2.0

1/16 2 2.7.2.0

1/17 2 2.7.2.0

1/18 3 2.7.2.0

1/19 3 2.7.2.0

1/20 3 2.7.2.0

.

.

.

Modem board HW version info:

Slot 1:

Carrier card:

number_of_ports= 60, max_modules= 10

Manufacture Cookie Info:

EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x47,

Board Hardware Version 1.0, Item Number 73-2393-03,

Board Revision A0, Serial Number 10081386,

PLD/ISP Version 5.9, Manufacture Date 12-Oct-1998.

Modem Module 0

Manufacture Cookie Info:

EEPROM Type 0x0101, EEPROM Version 0x01, Board ID 0x06,

Board Hardware Version 1.0, Item Number 73-2522-02,

Board Revision C48, Serial Number 09828503,

PLD/ISP Version <unset>, Manufacture Date 25-Oct-1998.

Modem Module 1

Manufacture Cookie Info:

EEPROM Type 0x0101, EEPROM Version 0x01, Board ID 0x06,

Board Hardware Version 1.0, Item Number 73-2522-02,

Board Revision C48, Serial Number 08559439,

PLD/ISP Version <unset>, Manufacture Date 21-Oct-1998.

------------------ show modem ------------------

Codes:

* - Modem has an active call

C - Call in setup

T - Back-to-Back test in progress

R - Modem is being Reset

p - Download request is pending and modem cannot be used for taking calls

D - Download in progress

B - Modem is marked bad and cannot be used for taking calls

b - Modem is either busied out or shut-down

d - DSP software download is required for achieving K56flex connections

! - Upgrade request is pending

Avg Hold Inc calls Out calls Busied Failed No Succ

Mdm Time Succ Fail Succ Fail Out Dial Answer Pct.

1/0 00:00:00 0 0 0 0 0 0 0 0%

1/1 00:00:00 0 0 0 0 0 0 0 0%

1/2 00:00:00 0 0 0 0 0 0 0 0%

1/3 00:00:00 0 0 0 0 0 0 0 0%

1/4 00:00:00 0 0 0 0 0 0 0 0%

1/5 00:00:00 0 0 0 0 0 0 0 0%

1/6 00:00:00 0 0 0 0 0 0 0 0%

1/7 00:00:00 0 0 0 0 0 0 0 0%

1/8 00:00:00 0 0 0 0 0 0 0 0%

1/9 00:00:00 0 0 0 0 0 0 0 0%

1/10 00:00:00 0 0 0 0 0 0 0 0%

1/11 00:00:00 0 0 0 0 0 0 0 0%

1/12 00:00:00 0 0 0 0 0 0 0 0%

1/13 00:00:00 0 0 0 0 0 0 0 0%

1/14 00:00:00 0 0 0 0 0 0 0 0%

1/15 00:00:00 0 0 0 0 0 0 0 0%

1/16 00:00:00 0 0 0 0 0 0 0 0%

1/17 00:00:00 0 0 0 0 0 0 0 0%

1/18 00:00:00 0 0 0 0 0 0 0 0%

1/19 00:00:00 0 0 0 0 0 0 0 0%

1/20 00:00:00 0 0 0 0 0 0 0 0%

.

.

.

Command Reference

.

- show tech-support modem

- show tech-support spe

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© <year> Cisco Systems, Inc. All rights reserved.

PIAFS Wireless Data Protocol Version 2.1 for Cisco MICA Modems

Feature History

Release

Modification

12.1(2)XH

This feature was introduced.

12.2(2)XA

New Modem States and Link Information Parameters were added for Version 2.1 (supported on Cisco AS5300 universal access servers only).

12.2(2)XB1

This feature was supported on Cisco AS5800 platforms.

12.2(11)T

This feature was integrated into Cisco IOS Release 12.2(11)T.

This document describes the Personal Handyphone Internet Access Forum Standard (PIAFS), Version 2.1 feature using Cisco MICA modems for Cisco AS5300 and Cisco AS5800 universal access servers. PIAFS Version 2.1 is supported with Cisco IOS Software Release 12.2(2)XB1 or 12.2(11)T.

This document includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Prerequisites

- Configuration Tasks

- Configuration Examples

- Command Reference

- Glossary

Feature Overview

This feature adds support for the PIAFS 2.1 protocol (T1 only) with Cisco MICA modems on Cisco AS5300 Cisco AS5800 universal access servers. PIAFS provides data connectivity between a client computer and a remote access server (RAS) using the Personal-Handyphone-System (PHS) digital cellular telephone system. PIAFS 2.1 allows the modem to shift speed during a connection between 32,000 and 64,000 bps when initiated by a remote terminal adapter (TA). PIAFS provides data connectivity between a client computer and remote access server (RAS) using the PHS digital cellular telephone system. Figure 1 shows a typical PIAFS RAS environment.

Figure 1 PIAFS Configuration

Note Cisco MICA Portware Version 8.2.x.x does not support modem modulations (for example, V.90), V.110, or fax. If non-PIAFS features are desired, other portware images, such as Cisco MICA Portware Version 2.7.3.0 can be loaded onto other Hex Modem Modules (HMMs) or Double Density Modem Modules (DMMs) in your Cisco AS5x00 universal access server. See the Restrictions section for more information.

The following PIAFS 2.1 features are supported on the Cisco AS5x00 platforms:

- In-band negotiation and synchronization of variable-speed Type 2 data transmission. This allows variable Type 2 devices such as Cisco MICA modems to connect with Type 1 and Type 2 initiating devices. A PIAFS 2.1 connection can be with two Type 2 devices, two Type 1 devices, or a Type 1 and a Type 2 device. Operational Cisco MICA is always Type 2, but it can communicate with Type 1 and Type 2 devices as well as with systems running PIAFS 1.x and 2.0.

A Type 2 device cannot directly sense traffic channels (TCH). The TCH is the number of 32k channels bound to a call. If the Type 2 device loses synchronization, the device assumes that the speed has changed, so the device periodically switches its I.460 (1988 ITU-T standard) intermediate rate adaptation function on and off while it is out of synchronization until it achieves sync or fails to resynchronize. An originating Type 2 device switches every 1.6 to 1.8 seconds; a receiving Type 2 device switches every 200 milliseconds. A Type 2 device is notified of speed changes from within the PIAFS protocol.

A Type 1 device directly senses the number of 32k radio frequency (RF) channels bound to a call. It can either sense the total number of channels that are currently bound (TCH) or issue an early warning of TCH change (a Preliminary Signal, or PS). If a Type 1 device senses a TCH speed change, it will directly switch to the new speed, turning its I.460 intermediate rate adaptation on or off as necessary. If a PS change is sensed, the device sends a protocol message before switching its I.460 logic. Both the originating and the receiving device can be Type 1, depending on whether each device can sense TCH or PS.

- Fixed user rate negotiation with PIAFS 2.0 and 1.X clients.

- Real-time statistics for negotiated parameters and speed changes.

- Mixed Cisco MICA (PIAFS and modem/fax/data) images on a DFC. A Cisco AS5300 universal access server running Cisco IOS Release 12.2.(2)XA will support both PIAFS 2.1 and modem calls together, on different SPEs in a multiple SPE configuration. See the Restrictions section for more information.

- AT commands (modemcaps)—PIAFS is controlled by entering the MSC=&F&D2 modemcap. Enter the no flush-at-activation command in the line configuration if Point-to-Point Protocol (PPP) is desired.

- S34 S-register—The S34 S-register interfaces with new PHS or TA devices in the field by selectively inhibiting or enabling parts of the PIAFS 2.1 protocol. This S-register allows the use of non standard values.

.

.

PIAFS Protocol

The PHS PIAFS feature specifies a transmission system that uses the PHS 64,000 bps/32,000 bps unrestricted digital bearer, which allows dynamic data rate change between 32 and 64 kbps during a call. The PIAFS protocol allows for these dynamic data rate changes. The PIAFS terminal adapter (TA) module works like a modem or a V.110 module by using the same call-setup Q.931 message, but differs by its use of the 32k and 64k user rate and the ability to support ISDN bearer channel capability and calling party subaddress.

Note PIAFS Version 2.1 with Cisco IOS Release 12.2(2)XA, 12.2(2)XB1, or 12.2(11)T requires Cisco IOS Plus images. See the Restrictions section.

With the PIAFS protocol, a call is initiated from the client computer or personal digital assistant (PDA) through a terminal adapter (TA), which is typically connected to the computer using a PCMCIA slot, serial interface, or USB interface. The TA contains PIAFS functionality and either is connected (or integrated) with a PHS handset for wireless communications, or is connected directly to the telco network using an ISDN BRI line. For wireless operation, the PHS base station allocates either a 32- or 64-kbps (user rate) channel for the connection with the client TA. The client and RAS perform PIAFS synchronization and feature negotiation to set up an error-correcting communication channel with optional V.42bis data compression.

PHS manages the user channel capacity based on the aggregate bandwidth used at the local base station to maximize the number of supported users. In return, the channel capacity for each user is reduced. PIAFS 2.1 allows the user rate to change during a call as base station use changes. In previous PIAFS versions, the data rate was established at call setup and remained fixed during the call. The dynamic user rate change capability introduced in PIAFS 2.1 uses RF channel capacity more efficiently and reduces the occurrence of call denial in heavily utilized cells.

Note Some TAs support both PIAFS 2.0 and 2.1 protocols, but the negotiation message that is sent to the initiated server unit can indicate a preference for 2.0. Cisco MICA might create a 2.0 connection rather than a 2.1 connection, if a 2.0 preference is indicated. This is a normal Cisco MICA occurrence. Cisco MICA continues to support earlier protocol versions and works with older PHSs and TAs.

Benefits

New Link Information Parameters

or 2.0 and PIAFS 2.1.

New Modem States

Two new modem states have been defined for Cisco AS5300 universal access servers in this release:

- Steady PIAFS Resync (with a value of 80)—Indicates that a PIAFS channel has lost synchronization and is performing a resynchronization.

- Steady PIAFS Speedshift (with a value of 85)—Indicates that a PIAFS channel has just negotiated a speed shift change (for example, from 32,000 bps to 64,000 bps or from 64,000 bps to 32,000 bps).

command. The states are displayed under the Modem State event heading. The modem states tell you when the network changed the connection speed (added or subtracted 32k channels). The number of 32k channels bound to a call is also known as traffic channel (TCH).

Note Speedshifting must be initiated by the client or Telco.

No Changes to Configuration

There are no new configuration parameters necessary to use the PIAFS 2.1 capabilities.

Restrictions

Cisco MICA Portware Version 8.2.x.x supports the PIAFS protocol only and does not support modem modulations (for example, V.90), V.110, or fax. Similarly, standard (non-PIAFS) Cisco MICA portware versions cannot support the PIAFS protocol.

The following additional restrictions apply to this release:

- PIAFS Version 2.1 with Cisco IOS Release 12.2(2)XAm 12.2(2)XB1, or 12.2(11)T requires Cisco IOS Plus images. The following Cisco IOS Plus images are supported with this feature:

– Desktop Plus

– Desktop Voice Plus

– Enterprise Plus

– Enterprise Plus IPSEC 56

– Enterprise Voice Plus

– IP Plus

– IP Plus IPSEC 56

– IP/Voice Plus

- PIAFS and non-PIAFS functionality cannot be mixed on the same SPE. Each SPE can only support one version of Cisco MICA portware at a time. A single SPE (6 Cisco MICA modem sessions with an HMM, or 12 Cisco MICA modem sessions with a DMM) can support only one of the following:

– PIAFS 2.1 calls with Portware Version 8.2.3.0

Or

– Modem modulations using standard (non-PIAFS) Cisco MICA modem portware releases (for example, Version 2.7.3.0).

The portware you are running determines SPE functionality.

- PIAFS 2.1 is only supported over a T1 Interface with isdn switch-type set to primary-ntt .

- Resource services must be used with Cisco MICA modems.

- Modem pooling and resource pool management are not compatible.

- Only the V.42bis data compression protocol is supported.

- Real-Time Transport Protocol (RTP), user-control frames, and continuous frames are not supported.

- The PIAFS protocol is contained in a special Cisco MICA PIAFS only image with no modem/fax support.

Related Documents

- AT Command Set and Register Summary for Cisco MICA Six-Port Modules with PIAFS

- Configuring the NAS for Basic Dial Access

- Release Notes for Cisco MICA Portware Version 8.2.3.0 on Cisco AS5x00 Universal Access Servers

- SPE and Firmware Download Enhancements

- Cisco AS5300 universal access servers Cisco MICA release notes index page

- Configuration documents for Cisco AS5800

- Cisco AS5x00 Cisco MICA 6-Port and 12-Port Modem Module Portware/Cisco IOS Software Compatibility Matrixes

- Cisco AS5300 access servers, Appendix A, “Managing Modems,” and Appendix B, “Rom Monitor,” in the Cisco AS5300 Universal Access Server Software Configuration Guide

- Modem Management Commands

- Cisco IOS Dial Services Command Reference

- Cisco IOS Dial Technologies Configuration Guide, Release 12.2

- Quick Start Guide, Cisco AS5300 Universal Access Server Install and Configure

- V.90 and RFC-2217 dialout support for fax/data

Note The Cisco DialOut Utility (CDU) is no longer supported. Refer to the Sample NAS Configurations for Cisco DialOut Utility document for information about RFC-2217 reverse TELNET support.

Technical Assistance Center

http://www.cisco.com/jp/

Determining Platform Support Through Cisco Feature Navigator

Cisco IOS software is packaged in feature sets that are supported on specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Cisco Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.

To access Cisco Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:

Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:

Availability of Cisco IOS Software Images

Platform support for particular Cisco IOS software releases is dependent on the availability of the software images for those platforms. Software images for some platforms may be deferred, delayed, or changed without prior notice. For updated information about platform support and availability of software images for each Cisco IOS software release, refer to the online release notes or, if supported, Cisco Feature Navigator.

Supported Platforms

- Cisco AS5300

- Cisco AS5800

Determining Platform Support Through Cisco Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Cisco Feature Navigator is a web-based tool that enables you to determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.

.

Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:

Availability of Cisco IOS Software Images

Platform support for particular Cisco IOS software releases is dependent on the availability of the software images for those platforms. Software images for some platforms may be deferred, delayed, or changed without prior notice. For updated information about platform support and availability of software images for each Cisco IOS software release, refer to the online release notes or, if supported, Cisco Feature Navigator.

Supported Standards, MIBs, and RFCs

Standards

No new or modified standards are supported by this feature.

MIBs

- CISCO-MODEM-MGMT-MIB

- CISCO-CALL-RESOURCE-POOL-MIB

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

If Cisco MIB Locator does not support the MIB information that you need, you can also obtain a list of supported MIBs and download MIBs from the Cisco MIBs page at the following URL:

To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:

RFCs

No new or modified RFCs are supported by this feature.

Prerequisites

- You must have Cisco MICA Portware Version 8.2.3.0 or higher.

- You must be running Cisco IOS Release 12.2(2)XA, 12.2(2)XB1, or 12.2(11)T.

- A minimum of 64 MB must be available on the DMM cards.

- PHS 64,000 bps requires the allocation of two 32k channels.

- PIAFS portware images are not bundled with Cisco IOS software, so you must copy the image to Flash memory, and specify the image to use using spe commands.

commands to download portware images.

Note The Cisco AS5300 requires 128MB of memory for systems using Cisco IOS Release12.1(5)T and later releases.

Configuration Tasks

See the following sections for configuration tasks for the PIAFS feature. Each task in the list is identified as either required or optional.

- Configuring PIAFS (required)

- Verifying PIAFS (optional)

- Configuring a Resource-Pool Group Resource (optional)

- Verifying Resource-Pool Group Resource (optional)

Note When configuring a voice port, use the following configuration designations:

For the Cisco AS5300, port designation is port.

Configuring PIAFS

To configure PIAFS, use the following commands in interface configuration mode.

Command

Purpose

Step 1

Router(config)# interface serial controller:channel

Enters interface configuration mode for a D-channel serial interface.

Step 2

Router(config-if)# isdn piafs-enabled

Enables the Primary Rate Interface (PRI) to take PIAFS calls on Cisco MICA modems.

Step 3

Router(config-if)# exit

Exits interface configuration mode.

Verifying PIAFS

commands in privileged EXEC mode:

command to view PIAFS call information.

piafs_diald# show mod op 1/3

Modem(1/3) Operational-Status:

Parameter #0 Disconnect Reason Info: (0x0)

Type (=0 ): <unknown>

Class (=0 ): Other

Reason (=0 ): no disconnect has yet occurred

Parameter #1 Connect Protocol: PIAFS 2.1

Parameter #2 Compression: V.42bis both

Parameter #3 EC Retransmission Count: 0

Parameter #4 Self Test Error Count: 0

Parameter #5 Call Timer: 36 secs

Parameter #6 Total Retrains: 0

Parameter #7 Sq Value: 7

Parameter #8 Connected Standard: ISDN

Parameter #9 TX,RX Bit Rate: 64000, 64000

Parameter #11 TX,RX Symbol Rate: 0, 0

Parameter #13 TX,RX Carrier Frequency: 0, 0

Parameter #15 TX,RX Trellis Coding: (n/a), (n/a)

Parameter #16 TX,RX Preemphasis Index: 0, 0

Parameter #17 TX,RX Constellation Shaping: (n/a), (n/a)

Parameter #18 TX,RX Nonlinear Encoding: (n/a), (n/a)

Parameter #19 TX,RX Precoding: (n/a), (n/a)

Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm

Parameter #21 Signal Noise Ratio: 0 dB

Parameter #22 Receive Level: 0 dBm

Parameter #23 Frequency Offset: 0 Hz

Parameter #24 Phase Jitter Frequency: 0 Hz

Parameter #25 Phase Jitter Level: 0 degrees

Parameter #26 Far End Echo Level: 0 dBm

Parameter #27 Phase Roll: 0 degrees

Parameter #28 Round Trip Delay: 0 msecs

Parameter #30 Characters transmitted, received: 14, 0

Parameter #32 General Portware Information: 0

Parameter #33 PPP/SLIP packets transmitted, received: 0, 0

Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0

Parameter #36 EC packets transmitted, received OK: 1, 0

Parameter #38 Moving Average of EC packets (Received BAD/ABORTED): 0

Parameter #39 Robbed Bit Signalling (RBS) pattern: 0

Parameter #40 Digital Pad: (n/a)

Digital Pad Compensation : None

Parameter #42 SS7/COT Status: 0

Parameter #43 V110/PIAFS frames received bad: 0

Parameter #44 V110/PIAFS frames received good: 3578

Parameter #45 V110/PIAFS frames transmitted: 3578

Parameter #46 V110/PIAFS sync lost: 0

Parameter #93 PIAFS RTF: 11

Parameter #120 Total Speedshifts: 0

Line Shape:

*

command in privileged EXEC mode:

piafs_diald# show mod log 1/3

Modem 1/3 Events Log:

*Mar 30 01:48:42.207: ISDN incoming called number: 2015551111

*Mar 30 01:48:42.563: Modem State event:

State: Call Setup

*Mar 30 01:48:42.563: Modem State event:

State: Connect

*Mar 30 01:48:42.563: Modem State event:

State: Link

*Mar 30 01:48:42.563: Modem State event:

State: Train Up

*Mar 30 01:48:42.563: Modem State event:

State: EC Negotiating

*Mar 30 01:48:54.567: Modem State event:

State: Steady

*Mar 30 01:48:54.567: Static event:

Connect Protocol: PIAFS 2.1

Compression: V.42bis both

Connected Standard: ISDN

TX,RX Symbol Rate: 0, 0

TX,RX Carrier Frequency: 0, 0

TX,RX Trellis Coding: (n/a), (n/a)

Frequency Offset: 0 Hz

Round Trip Delay: 0 msecs

TX,RX Bit Rate: 64000, 64000

Robbed Bit Signalling (RBS) pattern: 0

Digital Pad: (n/a)

Digital Pad Compensation : None

*Mar 30 01:48:54.567: Dynamic event:

Sq Value: 7

Signal Noise Ratio: 0 dB

Receive Level: 0 dBm

Phase Jitter Frequency: 0 Hz

Phase Jitter Level: 0 degrees

Far End Echo Level: 0 dBm

Phase Roll: 0 degrees

Total Retrains: 0

EC Retransmission Count: 0

Characters transmitted, received: 0, 0

General Portware Information: 0

PPP/SLIP packets transmitted, received: 0, 0

PPP/SLIP packets received (BAD/ABORTED): 0

EC packets transmitted, received OK: 0, 0

Moving Average of EC packets (Received BAD/ABORTED): 0

V110/PIAFS frames received bad: 0

V110/PIAFS frames received good: 27

V110/PIAFS frames transmitted: 28

V110/PIAFS sync lost: 0

PIAFS RTF: 11

Total Speedshifts: 0

Configuring a Resource-Pool Group Resource

Command

Purpose

Step 1

Router(config)# resource-pool group resource piafs

Creates a resource group (piafs) for resource management.

Step 2

Router(config-resource)# exit

Exits configuration mode.

Verifying Resource-Pool Group Resource

command to view resource-pool group resource information:

Router# show resource-pool resource piafs

0 resources in the resource group

0 resources currently active

0 calls accepted in the resource group

0 calls rejected due to resource unavailable

0 calls rejected due to resource allocation errors

never since last clear command

Configuration Examples

command:

version 12.2

service timestamps debug datetime msec localtime show-timezone

service timestamps log datetime msec localtime show-timezone

service password-encryption

!

hostname travis-nas-01

!

aaa new-model

aaa authentication login default local

aaa authentication login NO_AUTHENT none

aaa authorization exec default local if-authenticated

aaa authorization exec NO_AUTHOR none

aaa authorization commands 15 default local if-authenticated

aaa authorization commands 15 NO_AUTHOR none

aaa accounting exec default start-stop group tacacs+

aaa accounting exec NO_ACCOUNT none

aaa accounting commands 15 default stop-only group tacacs+

aaa accounting commands 15 NO_ACCOUNT none

enable secret 5 $1$LsoW$K/qBH9Ih2WstUxvazDgmY/

!

username admin privilege 15 password 7 06455E365E471D1C17

username gmcmilla password 7 071824404D06140044

username krist privilege 15 password 7 0832454D01181118

!

!

!

!

call rsvp-sync

shelf-id 0 router-shelf

shelf-id 1 dial-shelf

!

!

!

resource-pool disable

!

resource-pool group resource piafs

Command Reference

.

- isdn piafs-enabled

Glossary

—Call Switching Module.

—Double Density Modem Module. A Cisco MICA hardware package with 12 modems on a daughter board unit.

—European equivalent of T1. Thirty two channels of 64000 Hz—one for framing, one for signaling.

—Hex Modem Module. A Cisco MICA hardware package with six modems on a daughter board unit.

—(1988 ITU-T standard). Specifies procedures used to adapt a PIAFS 32k stream to a 64k ISDN B-channel.

—intermediate rate. Data rate used to communicate between the PHS base station and the client TA. The two rates supported are 32 and 64 kbps.

—Integrated Services Digital Network.

—logical link control.

—Modem ISDN channel aggregation.

—personal digital assistant

—Personal-Handyphone-System.

—PHS Internet Access Forum Standard. ITU-T standard for support by ISDN of data terminal equipment with V-series type interfaces.

—Software that runs on the Cisco MICA HMM or DMM.

—Point-to-Point Protocol.

—Primary Rate Interface.

—preliminary signal. This signal, if present, gives advance notice of speed changes to a Type 1 device.

—ISDN User-Network Interface Layer 3 specification for basic call control.

—remote access server.

—traffic channel. The 32k bearer channel for user data. PIAFS 2.1 can bundle up to 2 channels of data for a total data rate of 64k. For PIAFS 2.1, the total number of channels can be shifted up or down dynamically during a call. PIAFS 2.1 on Cisco MICA, however, cannot sense the total number of TCHs, seeing only the loss of synchronization that occurs when the channels shift. Standard PIAFS algorithms (switching IR every 200 msec) allow PIAFS 2.1 on Cisco MICA to synchronize to a new speed without sensing the total number of TCHs. When PIAFS 2.1 on Cisco MICA is originating PIAFS 2.1 calls (TEST), it locks to a particular IR, simulating a TCH change. PIAFS 2.1 on Cisco MICA is not intended to originate calls in an operational mode, so TCH sensing and T010/T011 timers are not implemented.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001–2009 Cisco Systems, Inc. All rights reserved.

V.92 and V.44 Support for Digital Modems

The V.92 and V.44 Support for Digital Modems feature supports the V.92 Modem on Hold and V.92 Quick Connect portions of the new V.92 modem standard, and the new V.44 LZJH compression standard based on Lempel-Ziv, on the Cisco 3600 and 3700 router platforms.

Feature Specifications for V.92 and V.44 Support for Digital Modems

Feature History

Release

Modification

12.2(11)YT

This feature was introduced.

12.2(15)T

This feature was integrated into Cisco IOS Release 12.2(15)T.

Supported Platforms

Cisco 3620; Cisco 3640; Cisco 3640A; Cisco 3660; Cisco 3725; Cisco 3745

Finding Support Information for Platforms and Cisco IOS Software Images

at the login dialog box and follow the instructions that appear.

Contents

- Prerequisites for V.92 and V.44 Support for Digital Modems

- Restrictions for V.92 Support for Digital Modems

- Information About V.92 and V.44 Support for Digital Modems

- How to Use the V.92 and V.44 Support for Digital Modems Feature

- Additional References

Prerequisites for V.92 and V.44 Support for Digital Modems

Client modem vendors must supply their own utilities to enable the V.92 Modem on Hold feature with each client modem.

Restrictions for V.92 Support for Digital Modems

- Cisco modems do not support pulse code modulation (PCM) upstream as defined in the V.92 International Telecommunication Union (ITU) standard. Cisco hardware will, however, interoperate with modems that support PCM upstream.

- There is no standard method for notifying remote or user applications that a modem session has been placed on hold. Extending timeouts or increasing the maximum number of attempts to perform certain operations might be necessary. No e-mail data should be lost because of on-hold times.

- When a modem on hold (MOH) transaction returns to the data-connected state, it retains the same IP network connection. Any other connected application might not be returned to its prior state, depending on the application’s data transaction requirements during the MOH active state.

- Configuration of the features described in this document using S-registers is carried out by using modemcaps (modem attention or AT commands). Cisco IOS software does not check these values to guarantee that they are valid. The behavior of invalid values is determined by the module.

- Authorization of MOH is not provided as a standard service by RADIUS. However, RADIUS provides a vendor-specific attribute (VSA) capability that can be used to extend authorization mechanisms. This capability is already used by Cisco routers to provide other custom services.

- Cisco IOS software is packaged as multiple program image types with varying capabilities. Because not all modem interfaces support MOH and because images may be built to support specific modem types, not all software images contain functions to control MOH. In addition, the modems that do support MOH each implement their control functions differently. Therefore, registry functions are used to interface between RADIUS, local authorization, and MOH control for modems.

- Server-initiated MOH is not supported.

- During a suspended modem session, some data might be dropped. The ISP idle timer, which disconnects a dial-in user if no data is exchanged for a period of time, should be reset and suspended while a connection is on hold.

Note Many client modems used in Europe are known to have problems with the MOH feature. The vendors are aware of the issue and are working to correct it. If you are a customer having trouble with the MOH feature in Europe, we suggest that you contact the client modem vendor to verify that the modem complies with the telephony signaling for call waiting, caller ID, and three-way calling in their particular country.

Information About V.92 and V.44 Support for Digital Modems

The following sections provide information about the V.92 and V.44 Support for Digital Modems feature.

- ITU-T V.92 Modem Standard

- V.44 LZJH Compression

ITU-T V.92 Modem Standard

The ITU-T V.90 modem standard recommendations have been enhanced with V.92, a new standard that meets the need for a digital modem and analog modem pair on the Public Switched Telephone Network (PSTN). V.92 improves the upstream data signaling rate and adds new features that enhance modem usability.

This feature supports the following parts of the V.92 modem standard:

- V.92 Modem on Hold

- V.92 Quick Connect

V.92 is implemented at the modem level as new modem protocols and standards. The new V.92 features co-reside with existing portware features and have no impact on the hardware configuration of either the hex MICA technologies module (HMM) or dual MICA technologies module (DMM), including on memory requirements.

V.92 Modem on Hold

V.92 Modem on Hold allows a dial-in customer to suspend a modem session to answer an incoming voice call or to place an outgoing call while engaged in a modem session.

When the dial-in customer uses V.92 Modem on Hold to suspend an active modem session to engage in an incoming voice call, the Internet service provider (ISP) modem listens to the original modem connection and waits for the dial-in modem to resume the connection. When the voice call ends, the modem signals the telephone system to end the second call and return to the original modem connection, then the modem signals the ISP modem that it is ready to resume the modem call. Both modems renegotiate the connection, and the original exchange of data continues.

Note This feature is designed for use on telephone lines that are configured for the call-waiting service; call-waiting signals trigger the suspension of the modem session. If call-waiting service is not present on the subscriber’s line, callers receive a busy signal, and the modem session is not interrupted.

Use of the V.92 Modem on Hold feature for Cisco MICA portware can be controlled globally using AT commands (modemcaps) or can be controlled on a per-caller basis using the RADIUS distributed client/server system. (You are not required to have a RADIUS server to use the V.92 Modem on Hold feature.)

V.92 Modem on Hold AT Commands and S-Registers

lists additional S-register parameters used to enable and disable the feature.

Table 1 V.92 Modem on Hold S-Registers

Name

Register

Index

Default

Description

MOH Timeout

S62

63

0

MOH Disabled

0: MOH Disabled

1: 10 seconds

2: 20 seconds

3: 30 seconds

4: 40 seconds

5: 1 minute

6: 2 minutes

7: 3 minutes

8: 4 minutes

9: 6 minutes

10: 8 minutes

11: 12 minutes

12: 16 minutes

13: No limit

To disable V.92 Modem on Hold, you can use a modemcap (for example, s62=0s63=3s21=15s29=12) or set the S29 register to any number other than 12. You can also use the RADIUS VSA to disable MOH if the feature was initially enabled by the default value (modemcap).

Note If the feature is enabled using S29=12 and V.92 Modem on Hold is disabled using S62=0, statistics for the number of times a dial-in customer requests an on-hold function are tracked in the MOH link information parameters. However, completely disabling the feature by setting S29 to a value other than 12 disables the reporting of all MOH statistics.

.

RADIUS Authorization

Per-user control of V.92 Modem on Hold can be configured for caller authorization using a RADIUS server. RADIUS servers use the VSA capability to configure MOH for individual users. The current attribute=value protocol syntax has been extended with the new Modem on Hold attribute. You can enter an unsigned integer in the range from 0 through 65,535 that represents the maximum number of seconds that a modem may remain on hold, and which can extend from 10 seconds to an unlimited number of minutes.

Note Although the integer attribute values can be specified as any value in a contiguous range, V.92 specifications limit configuration to a limited set of values. Attribute values are rounded down to the next permitted value when they are used to configure a modem.

keyword, which allows the modem to remain on hold indefinitely.

If the V.92 Modem on Hold configuration is not present, or if it is not syntactically correct, the modem uses its default configuration for MOH. The default operation can be modified by using a modemcap string. Following authentication of a dial-in user, an additional control command is sent to the modem if the dial-in user does not have a default MOH configuration.

Note Code space requirements for RADIUS support is less than 2 KBs. There are no additional data space requirements.

V.92 Modem on Hold running on systems using RADIUS authorization increases the length of RADIUS response packets by approximately 20 bytes. RADIUS databases increase in size by approximately the same amount for each dial-in user with a nondefault MOH attribute value.

With RADIUS, authentication and authorization occur as part of the same process. When a caller connects to the access server, the caller enters a user ID and password in response to prompts from the access server. This information is formatted as a RADIUS request packet and is sent to the appropriate RADIUS server. If the user ID is valid and the password matches, the RADIUS server responds with a packet containing authorization data for the connection. This authorization data contains the MOH configuration if it is present in the RADIUS database.

The access server interprets the response from the RADIUS server and performs any actions associated with the authorization data. For V.92 Modem on Hold, a command is sent from the Cisco IOS host to the Cisco MICA channel to set the MOH parameters. No confirmation from the channel is required.

When the client modem requests a V.92 Modem on Hold operation, the modem switches to an on-hold state, which prevents further data from being queued to the connection. When the Cisco IOS software receives the request to go on hold, any transmit packets queued to local Cisco IOS queues (packets not already posted to the queues shared between the Cisco IOS software and the modem) are discarded. This mechanism reduces the possibility that stale data will be transmitted to the modem when the connection is reactivated. It also reduces the number of buffer resources that are unavailable while a modem is on hold.

Note When a RADIUS server is used, placement of commas is important. The asterisk in the modem-on-hold attribute indicates that the attribute is optional. If a modem does not support V.92 Modem on Hold, then the call might continue anyway. If the asterisk is replaced by an equal sign (=), the attribute is required, and modems that do not support MOH terminate the calls following authentication. The value of the attribute is the number of seconds allowed for the on-hold state. This value is rounded down by the Cisco IOS software to one of the permissible values. The number can be replaced with the inf command, which allows unlimited on-hold time. Case is significant for both attribute names and values.

Note If your router is configured for RADIUS, the RADIUS server must be accessible to the router. The server must also be capable of responding to authentication requests with VSA attributes.

V.92 Quick Connect

V.92 Quick Connect speeds up the client-to-server startup negotiation, reducing the overall connect time by up to 30 percent. The client modem retains line condition information and characteristics of the connection to the ISP, which reduces connect time by avoiding some of the initial signal handshaking.

V.92 Quick Connect AT Commands and S-Registers

AT commands are used to configure V.92 Quick Connect on Cisco MICA platforms.

lists the S-registers used to enable and disable the V.92 Quick Connect feature.

Table 2 Quick Connect (QC) Config S-Registers

Name

Register

Index

Default

Description

V.92 QC Config

S63

64

0x3

QC Enabled

ANSpcm Level –12 dBm

Bit 0: QC Enable

0: Disabled

1: Enabled

Bits 1–2 ANSpcm Level

00: –9 dBm

01: –12 dBm

10: –15 dBm

11: –18 dBm

Note If the V.92 Modem on Hold feature is enabled using S29=12, and QC is disabled using S63=0, then the QC Exchange Link Information Parameter is updated to show if QC was requested. However, completely disabling the feature by setting S29 to a value other than 12 disables the reporting of QC requests.

.

V.44 LZJH Compression

shows positive results.

V.44 supports automatic switching between compressed and transparent modes on supported platforms. Automatic switching allows overall performance gain without loss in throughput for file streams that are not compressible.

V.44 is globally controlled through dialed number identification service (DNIS), calling line identification (CLID), and resource pool manager server (RPMS) virtual groups, and performance improvement is determined by the LZJH algorithms.

have been extended to show V.44 configuration status. New disconnect reasons help manage V.44 session status and debugging.

V.44 AT Commands and S-Registers

V.44 compressor/decompressor optimizes throughput and the CSR using the standard AT command interface. New AT commands are provided so that V.44 can be enabled or disabled at the modem level. Modemcaps (dial in) or chat scripts (dial out) are required to enable or disable V.44 globally on the access server.

commands are used for obtaining V.44 status. These commands modify the operation of S21 to enable and disable the algorithm.

shows additional S-register values used with the V.44 feature. V.44 is enabled by default.

Table 3 V.44 S-Registers (Existing)

Name

Register

Index

Default

New Values

Data Compression

S21

NextPort 0x800b

MICA 11

0xf

Bit 2: V.44 Tx

Bit 3: V.44 Rx

Table 4 V.44 S-Registers (Redefined)

Name

Register

Index

Default

Description

V.44 Max Tx Codewords

S65

NextPort 0x8042

MICA 66

2048

256–2048

V.44 Max Rx Codewords

S66

NextPort 0x8043

MICA 67

2048

256–2048

V.44 Max Tx String Length

S67

NextPort 0x8044

MICA 68

255

0–255 characters

V.44 Max Rx String Length

S68

NextPort 0x8045

MICA 69

255

0–255 characters

V.44 Max Tx History Size

S69

NextPort 0x8046

MICA 70

10240

256–10240 bytes

V.44 Max Rx History Size

S70

NextPort 0x8047

MICA 71

10240

256–10240 bytes

How to Use the V.92 and V.44 Support for Digital Modems Feature

Cisco IOS software is responsible for controlling the features and displaying the new statistics. There are no tasks associated with configuring this feature. However, you may find the following table listing commands for monitoring digital modems that support the V.92 and V.44 modem standards useful.

- Monitoring Cisco Modems

Monitoring Cisco Modems

To monitor Cisco digital modems that support the V.92 and V.44 modem standards, use the following show commands in privileged EXEC mode:

Command

Purpose

Displays the modem event log with oldest event first.

Displays the operational status of the specified ports or the specified port range.

Configuration Examples

None.

Additional References

For additional information related to V.92 and V.44 Support for Digital Modems feature, refer to the following references:

Related Documents

Related Topic

Document Title

Modem commands

Modem configuration and management

AT Commands and S Registers

Standards

Standards 1

Title

ITU-T

V.92 — “Enhancements to Recommendation V.90”

ITU-T

V.44 — “Data Compression Procedures”

1.Not all supported standards are listed.

1.Not all supported standards are listed.

MIBs

MIBs

MIBs Link

provide Cisco MIBs for the V.92 Modem on Hold and V.44 MIBs.

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

Table 5 Modem On Hold MIBs (Existing)

MIBs

Attribute

New Values

CISCO-MODEM-MGMT-MIB

cmDisconnectReason

modemDrMohClrd

modemDrMohTimeout

87

88

Table 6 V.44 MIBs (Existing)

MIBs

Attribute

New Values

CISCO-MODEM-MGMT-MIB

cmDisconnectReason

modemDrDcIllegalCodewordStepup

modemDrDcIllegalTokenEmptyNode

modemDrDcIllegalTokenTooLarge

modemDrDcReservedCommand

modemDrDcIllegalCharacterSizeStepup

modemDrDcRxDictionaryFull

modemDrDcRxHistoryFull

modemDrDcRxStringSizeExceeded

modemDrDcNegotiationError

modemDrDcCompressionError

94

95

96

97

98

99

100

101

102

103

CISCO-CALL-TRACKER-MODEM-MIB

CctmDataCompression

v44Tx

v44Rx

v44Both

6

7

8

CISCO-CALL-TRACKER-MODEM-MIB

cctmActiveSupportedDC

v44Rx

v44Tx

Bit 3

Bit 4

CISCO-CALL-TRACKER-MODEM-MIB

cctmHistorySupportedDC

v44Rx

v44Tx

Bit 3

Bit 4

Table 7 V.44 MIBs (Redefined)

MIBs

Attribute

Value

Old Name

New Name

CISCO-MODEM-MGMT-MIB

cmDisconnectReason

41

modemDrBadV42bisRxdata

modemDrDcGeneralError

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

x

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you.

Qualified users can establish an account on Cisco.com by following the directions found at this URL:

RFCs

RFCs

Title

None

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001-2008 Cisco Systems, Inc. All rights reserved.

V.92 Modem on Hold for Cisco AS5300 and Cisco AS5800 Universal Access Servers

Feature History

Release

Modification

12.2(2)XA

This feature was introduced on Cisco AS5350 and Cisco AS5400 universal gateways running NextPort firmware.

This feature was introduced on the Cisco AS5300 universal access server running Cisco MICA Portware Version 2.9.1.0.

12.2(2)XB

This feature was supported with Cisco IOS Release 12.2(2)XB.

12.2(2)XB1

This feature was supported on Cisco AS5800 universal access servers.

12.2(11)T

This feature was integrated into Cisco IOS Release 12.2(11)T and support was added for the Cisco AS5300 and Cisco AS5800 platforms.

This feature module introduces the V.92 International Telecommunication Union Telecommunication Standardization Sector (ITU-T) standard Modem on Hold (MOH) feature with Cisco MICA portware for use with Cisco IOS Release 12.2(2)XB1 and 12.2(11)T.

This document includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Prerequisites

- Configuration Tasks

- Monitoring and Maintaining Modem on Hold

- Configuration Examples

- Command Reference

- Glossary

Feature Overview

V.92

To remain current with industry needs, the ITU-T V.90 modem standard recommendations have been enhanced. The new standard, V.92, meets the need for a digital modem and analog modem pair on the Public Switched Telephone Network (PSTN). V.92 improves the upstream data signaling rate and adds new features that enhance modem usability.

This feature module introduces the V.92 Modem on Hold feature on Cisco AS5300 and Cisco AS5800 universal access servers with Cisco MICA Portware Version 2.9.1.0 and higher.

Note The other feature introduced with the new V.92 standard is V.92 Quick Connect, which is documented in the V.92 Quick Connect for Cisco AS5300 and Cisco AS5800 Universal Access Servers feature module. V.92 Modem On Hold and V.92 Quick Connect can be enabled independently of each other.

V.92 is implemented at the modem level as new modem protocols and standards. The new V.92 features co-reside with existing portware features and have no impact on the hardware configuration of either the HMM or DMM (including memory requirements). Cisco IOS software is responsible for controlling the features and displaying the new statistics. V.92 and V.44 support is bound with the rest of the Cisco IOS device driver components.

Note V.92 is packaged with V.44 in Cisco IOS software. For more information about V.44, refer to the

V.44 LZJH Compression for Cisco AS5300 and Cisco AS5800 Universal Access Servers feature module.

Note This feature does not support pulse code modulation (PCM) upstream as defined in the V.92 ITU standard. This feature does, however, interoperate with modems that support PCM upstream.

Modem on Hold

V.92 Modem on Hold allows a dial-in customer to suspend a modem session to answer an incoming voice call or to place an outgoing call while engaged in a modem session. When the dial-in customer uses Modem on Hold to suspend an active modem session to engage in an incoming voice call, the Internet service provider (ISP) modem listens to the original modem connection and waits for the dial-in customer’s modem to resume the connection. When the voice call ends, the modem signals the telephone system to end the second call and return to the original modem connection, then the modem signals the ISP modem that it is ready to resume the modem call. Both modems renegotiate the connection, and the original exchange of data continues.

Note This feature is designed for use on telephone lines that are configured for call-waiting service; call-waiting signals trigger the suspension of the modem session. If call-waiting service is not present on the subscriber’s line, callers receive a busy signal, and the modem session is not interrupted.

Figure 1 V.92 Modem on Hold for Cisco AS5300 and Cisco AS5800 Universal Access Servers

commands (modemcaps) or can be controlled on a per-caller basis using the RADIUS distributed client/server system.

Note You are not required to have a RADIUS server to use the Modem on Hold feature.

The following sections contain information about controlling the V.92 Modem on Hold feature:

- AT Commands (Modemcaps) and S-Registers

- RADIUS Authorization

AT Commands (Modemcaps) and S-Registers

lists additional S-register parameters used to enable and disable the feature.

To disable V.92 Modem on Hold, you can use a modemcap (for example, s62=0s63=3s21=15s29=12) or set the S29 register to any number other than 12. You can also use the RADIUS vendor-specific attribute (VSA) to disable Modem on Hold if the feature was initially enabled by the default value (modemcap).

Note If the feature is enabled using S29=12 and Modem on Hold is disabled using S62=0, statistics for the number of times a dial-in customer requests an on-hold are tracked in the MOH link information parameters. However, completely disabling the feature by setting S29 to a value other than 12 disables the reporting of all MOH statistics.

Table 1 V.92 Modem on Hold S-Registers

Name

Register

Index

Default

Description

Modem standard

S29

MICA 19

12 (V.92 enabled)

0 = V.34bis Automode, with V.32ter

1 = V.34bis Automode, without V.32ter

2 = reserved

3 = V.32bis Automode

4 = V22bis Automode

5 = K56Flex 1.1 Automode

6 = V.90 Automode

7 = MICA:SS7/COT

8 = V.110

9 = Reserved

10 = Reserved

11 = Reserved

12 = V.92 Auto-mode

MOH timeout

S62

MICA 63

0

0: MOH disabled

1: 10 seconds

2: 20 seconds

3: 30 seconds

4: 40 seconds

5: 1 minute

6: 2 minutes

7: 3 minutes

8: 4 minutes

9: 6 minutes

10: 8 minutes

11: 12 minutes

12: 16 minutes

13: No limit

RADIUS Authorization

Modem on Hold attribute. You can enter the following value for this attribute:

- An unsigned integer in the range 0 through 65,535—Represents the maximum number of seconds that a modem may remain on hold, which can range from ten seconds to an unlimited number of minutes.

Note Although the integer attribute values can be specified as any value in a contiguous range, V.92 specifications limit configuration to a limited set of values. Attribute values are rounded down to the next permitted value when they are used to configure a modem.

keyword, which allows the modem to remain on hold indefinitely.

If the Modem on Hold configuration is not present, or if it is not syntactically correct, the modem uses its default configuration for Modem on Hold. The default operation can be modified by using a modemcap string. Following authentication of a dial-in user, an additional control command is sent to the modem if the dial-in user does not have a default Modem on Hold configuration.

Note Code space requirements for RADIUS support is less than 2KBs. There are no additional data space requirements.

V.92 Modem on Hold running on systems using RADIUS authorization increases the length of RADIUS response packets by approximately 20 bytes. RADIUS databases increase in size by approximately the same amount for each dial-in user with a nondefault Modem on Hold attribute value.

With RADIUS, authentication and authorization occur as part of the same process. When a caller connects to the access server, the caller enters a user ID and password in response to prompts from the access server. This information is formatted as a RADIUS request packet and is sent to the appropriate RADIUS server. If the user ID is valid and the password matches, the RADIUS server responds with a packet containing authorization data for the connection. This authorization data contains the Modem on Hold configuration if it is present in the RADIUS database.

The access server interprets the response from the RADIUS server and performs any actions associated with the authorization data. For Modem on Hold, a command is sent from the Cisco IOS host to the Cisco MICA channel to set the Modem on Hold parameters. No confirmation from the channel is required.

When the client modem requests a Modem on Hold operation, the modem switches to an on-hold state, which prevents further data from being queued to the connection. When the Cisco IOS software receives the request to go on hold, any transmit packets queued to local Cisco IOS queues (packets not already posted to the queues shared between the Cisco IOS software and the modem) are discarded. This mechanism reduces the possibility that stale data will be transmitted to the modem when the connection is reactivated. It also reduces the number of buffer resources that are tied up while a modem is on hold.

Note When using a RADIUS server, placement of commas is important. The asterisk in the modem-on-hold attribute indicates that the attribute is optional. If a modem does not support Modem on Hold, then the call might continue anyway. If the asterisk is replaced by an “=”, the attribute is required, and modems that do not support Modem on Hold terminate the calls following authentication.

The value of the attribute is the number of seconds allowed for the on-hold state. This value is rounded by the Cisco IOS software to one of the permissible values. The number can be replaced with the inf command, which allows unlimited on-hold time. Case is significant for both attribute names and values.

Note If your router is configured for RADIUS, the RADIUS server must be accessible to the router. The server must also be capable of responding to authentication requests with VSA attributes.

Configuring V.92 Modem on Hold with RADIUS

If you use Radius to configure the Modem on Hold feature, use the modem-on-hold attribute, where the VALUE attribute is a nonnegative integer in seconds for maximum time on hold allowed. VALUE can be one of the following:

- modem-on-hold=VALUE—MOH support is required for call to be accepted.

- modem-on-hold*VALUE—MOH support is optional.

The following example shows RADIUS enabled where Modem on Hold is optional:

vendor-specific=9:1:modem-on-hold*VALUE

Note The examples shown below were established on the Cistron open-source server. Your server syntax may vary.

# This user can use MOH without time limits. (inf)

# MOH capability is not required for the connection (*)

testi Auth-Type = Local, Password = "test"

Service-Type = Login-User,

Cisco-AVPair = "modem-on-hold*inf"

# This user can use MOH for 30 seconds.

# MOH capability is not required for the connection.

test30 Auth-Type = Local, Password = "test"

Service-Type = Login-User,

Cisco-AVPair = "modem-on-hold*30"

# This user can not use MOH.

# MOH capability is not required for the connection.

test0 Auth-Type = Local, Password = "test"

Service-Type = Login-User,

Cisco-AVPair = "modem-on-hold*0"

# This user can not use MOH.

# But MOH capability IS required for the connection.

# If the user logs on to a device that does not support

# MOH (eg the console), he will be disconnected after

# authentication.

testr Auth-Type = Local, Password = "test"

Service-Type = Login-User,

Cisco-AVPair = "modem-on-hold=0"

# This user gets the default MOH setting.

# The default setting is disabled, unless overridden

# by a modemcap entry.

testx Auth-Type = Local, Password = "test"

Service-Type = Login-User

# This user can go on hold for 60 seconds

# in a PPP link. The service type determines

# which calls get the MOH setting.

lucy Auth-Type = Local, Password = "test"

Service-Type = Framed-User,

Cisco-AVPair = "modem-on-hold*60"

Note The service type defines when the AVPair is applied. For different RADIUS servers, the Cisco-AVPair syntax might be different, but the value in quotes does not change. Case is important: The entire text in quotes must be lowercase.

documentation.

Modem Enhancements for V.92 Modem On Hold

V.92 Modem on Hold feature:

- Disconnect Reasons

- Duration Limit Timer

- Modem on Hold Link Information Parameters

- Modem States

- New and Modified MIBs

Disconnect Reasons

lists the new Modem on Hold Disconnect Reasons.

Table 2 Modem On Hold Disconnect Reasons

Name

Description

DR_MOH_CLRD

Modem On Hold cleardown by modem

DR_MOH_TIMEOUT

Modem On Hold timeout value reached

Duration Limit Timer

The Modem on Hold duration limit timer is supported within dialed number ID service (DNIS), calling line ID (CLID), RADIUS (but not TACACS+), and global resource pool manager server (RPMS) virtual groups. This support permits ISPs to associate the Modem on Hold feature and its timer limit according to customer needs. When the Modem on Hold timer is active (a modem is on hold), it must take precedence over the idle timer. For example, if the idle value is five minutes and the Modem on Hold duration limit is ten minutes, the customer is permitted to be on another call for up to ten minutes without being disconnected after five minutes by the idle timer. The Modem on Hold timer value resets at the end of each on-hold session.

Modem on Hold Link Information Parameters

Table 3 Modem on Hold Link Information Parameters

Name

Description

MOH Status

0: Modem is not on hold

1: Modem is on hold

MOH Count

Number of times the modem is on hold

MOH Request Count

Number of times the modem received Modem on Hold requests.

Total MOH Time

Total holding time: 65,535 seconds maximum

Current MOH Time

Current holding time: 65,535 seconds maximum

Call Waiting Retrains

Number of times a retrain occurred due to a call-waiting signal

Modem States

This feature supports modem states, which are discrete states that a modem transitions through, during, and after negotiation with a client modem. These states include the Modem on Hold input state, the Steady input state, and the Steady, Steady Retrain, and Terminate output states.

New and Modified MIBs

Existing MIBs that show the status of modem settings have been extended to show V.92 Modem on Hold configuration status. New MIBs have been created to report the incidence of V.92 Modem on Hold request calls coming into the server and to monitor on-hold status.

Supported Module Firmware and Cisco IOS Software

V.92 Modem on Hold is supported on the following:

- Module Firmware—The module firmware is a combination of modem (Digital Signal Processor or DSP) firmware and the module controller firmware. It is responsible for the collection of statistics and the actual implementation of V.92, including additional required state transitions.

- Cisco IOS software—The Cisco IOS software is responsible for the control and statistics reporting of the new features, including modemcaps, RADIUS authorization, and command-line interface (CLI) support. See the “Related Documents” section for information about new Cisco IOS Release features.

- Boardware—On the Cisco AS5300 and Cisco AS5800 with Cisco MICA Portware Version 2.9.1.0 only. The boardware runs on the Amazon carrier card and provides the interface between Cisco IOS and the Cisco MICA module.

Benefits

Allows Voice Calls Without Interruption of Existing Modem Connection

V.92 Modem on Hold allows the origination and reception of voice calls without disturbing preexisting modem sessions. With Modem on Hold, calls can ring through to the dial-in user without requiring the expense of a second telephone line.

Per-Use Enabling

Service providers can enable Modem on Hold on a per-user basis for premium service opportunities.

Standard Modem Feature

V.92 is a standard modem feature that is offered as a no-cost upgrade to the installed system.

V.92 Compatibility

Modems that support V.92 are fully compatible with modems that do not support it. If a modem that supports Modem on Hold connects with a modem that does not support it, the modems will connect normally. However, the Modem on Hold function is not available for that call.

Restrictions

- Client modem vendors must supply their own utilities to enable Modem on Hold with each client modem.

- There is no standard method for notifying remote or user applications that a modem session has been placed on hold. Extending timeouts or increasing the maximum number of attempts to perform certain operations might be necessary. No e-mail data should be lost because of on-hold times.

- When a Modem on Hold transaction returns to the data-connected state, it retains the same IP network connection. Any other connected applications might not be returned to their prior state, depending on the application’s data transaction requirements during the Modem on Hold active state.

- Configuration of these features using S-registers is carried out by using modemcaps ( AT commands). Cisco IOS software does not check these values to guarantee that they are valid. The behavior of invalid values is determined by the module.

- Authorization of Modem on Hold is not provided as a standard service by RADIUS. However, RADIUS provides a vendor-specific attribute (VSA) capability that can be used to extend authorization mechanisms. This capability is already used by Cisco routers to provide other custom services.

- Cisco IOS software is packaged as multiple program image types with varying capabilities. Because not all modem interfaces support Modem on Hold and because images may be built to support specific modem types, not all software images contain functions to control Modem on Hold. In addition, the modems that do support Modem on Hold implement their control functions differently. Therefore, registry functions are used to interface between RADIUS, local authorization, and Modem on Hold control for modems.

- Server-initiated Modem on Hold is not supported.

- During a suspended modem session, some data might be dropped. The ISP idle timer, which disconnects a dial-in user if there is no data exchanged for a period of time, should be reset and suspended while a connection is on hold.

Note Many client modems used in Europe are known to have problems with the Modem on Hold feature. The vendors are aware of the issue and are working to correct it. If you are having trouble with the Modem on Hold feature in Europe, it is suggested that the customer contact the client modem vendor to verify that the modem complies with the telephony signaling for call waiting, caller ID, and 3-way calling in their particular country.

Related Features and Technologies

- V.92 Quick Connect

- V.44 LZJH data compression service

- Mindspeed CSMv6 hardware solution

Related Documents

- AT Command Set and Register Summary for MICA Six-Port Modules

- Call Tracker plus ISDN and AAA Enhancements for the Cisco AS5300

- Cisco AS5300 documentation index

- Cisco AS5800 documentation index

- Cisco IOS Release 12.2 Master Indexes

- Comparing NextPort SPE Commands to MICA Modem Commands

- New Features in Release 12.2(2)XB

- Release Notes for Cisco AS5300 Universal Access Servers, Cisco IOS Release 12.2(2)XA

- Release Notes for Cisco AS5300 Universal Access Servers, Cisco IOS Release 12.2(2)XB

- Cisco IOS Release 12.2T Cross-Platform Release Notes

- Cisco AS5800 Universal Access Server Release Notes

- Release Notes for Cisco MICA Portware Version 2.9.1.0 on Cisco AS5300 Universal Access Servers

- SPE and Firmware Download Enhancements

- V.44 LZJH Compression for Cisco AS5300 and Cisco AS5800 Universal Access Servers

- V.92 Quick Connect for Cisco AS5300 and Cisco AS5800 Universal Access Servers

Supported Platforms

- Cisco AS5300

- Cisco AS5800

Table 4 Cisco IOS Release and Platform Support for this Feature

Platform

12.2(2)XA

12.2(2)XB

12.2XB1

12.2(11)T

Cisco AS5300

X

X

X

X

Cisco AS5800

Not supported

Not supported

X

X

Determining Platform Support Through Cisco Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Cisco Feature Navigator is a web-based tool that enables you to determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.

Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:

Availability of Cisco IOS Software Images

Platform support for particular Cisco IOS software releases is dependent on the availability of the software images for those platforms. Software images for some platforms may be deferred, delayed, or changed without prior notice. For updated information about platform support and availability of software images for each Cisco IOS software release, refer to the online release notes or, if supported, Cisco Feature Navigator.

Supported Standards, MIBs, and RFCs

Standards

- V.44

- V.92 Modem on Hold

- V.92 Quick Connect

MIBs

- CISCO-MODEM-MGMT-MIB

- CISCO-CALL-TRACKER-MODEM-MIB

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

If Cisco MIB Locator does not support the MIB information that you need, you can also obtain a list of supported MIBs and download MIBs from the Cisco MIBs page at the following URL:

To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:

RFCs

No new or changed RFCs are supported by this feature.

Prerequisites

- Cisco IOS Release 12.2(2)XA, 12.2(2)XB, or 12.2(11)T

- V.92 MOH Portware DSP program memory required (in 16-bit words): 500

- Less than 50k bytes needed for CP memory

- Basic configuration of the Cisco AS5300 or Cisco AS5800 universal access server

- Upgraded modem firmware (Cisco MICA portware 2.9.1.0)

- Modems must be capable of supporting Modem on Hold

Configuration Tasks

None

Monitoring and Maintaining Modem on Hold

Use the following show commands in privileged EXEC mode.

Command

Purpose

Displays the event log with oldest event first.

Displays the operational status of the specified ports or the specified port range.

Configuration Examples

None

Command Reference

.

- show modem configuration

- show modem log

- show modem operational-status

Glossary

—command-line interface.

—Mindspeed modem hardware solution.

—call success rate.

—dial feature card.

—Digital Signal Processor. Microprocessor on which the modulation/demodulation process is carried out.

—Internet service provider.

—International Telecommunication Union Telecommunication Standardization Sector.

—Lempel-Ziv-Jeff-Heath data compression algorithm used in V.44.

—Modem ISDN channel aggregation. Used as a generic term to describe the Dial Technology Division (DTD) high-density modem technology.

—Modem on Hold functionality specified in V.92.

—Device driver architecture for Cisco IOS software that supports the NextPort hardware and software interfaces. Supports the Universal Port concept.

—pulse code modulation.

—Public Switched Telephone Network.

—Remote Dial-In User Service. Database for authenticating modem and ISDN connections and for tracking connection time.

—service processing element.

—Concept of a single device that can terminate one digital signaling level zero (DS0) with a data modem, fax modem, ISDN, or voice solution.

—Quick Connect functionality specified in V.92.

—ITU modem standard for LZJH data compression algorithm.

—ITU modem standard that contains Quick Connect, Modem On Hold, and PCM upstream.

—vendor-specific attribute (as used with RADIUS).

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidenta

© 2001-2009 Cisco Systems, Inc. All rights reserved.

V.92 Modem on Hold for Cisco AS5350, Cisco AS5400, and Cisco AS5850 Universal Gateways

Feature History

Release

Modification

12.2(2)XA

This feature was introduced on Cisco AS5350 and Cisco AS5400 universal gateways running NextPort firmware.

12.2(2)XB

This feature was supported with Cisco IOS Software Release 12.2(2)XB.

12.2(2)XB1

This feature was supported on Cisco AS5800 universal access servers and Cisco AS5850 universal gateways.

12.2(11)T

This feature was integrated into Cisco IOS Release 12.2(11)T and support was added for the Cisco AS5350, Cisco AS5400, Cisco AS5800, and Cisco AS5850 platforms.

This feature module introduces the V.92 International Telecommunication Union Telecommunication Standardization Sector (ITU-T) standard Modem on Hold (MOH) feature on NextPort/DFC-108NP-bearing platforms for use with Cisco IOS Releases 12.2(2)XB1 and 12.2(11)T.

This document includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Prerequisites

- Configuration Tasks

- Monitoring and Maintaining Modem on Hold

- Configuration Examples

- Command Reference

- Glossary

Feature Overview

V.92

To remain current with industry needs, the ITU-T V.90 modem standard recommendations have been enhanced. The new standard, V.92, meets the need for a digital modem and analog modem pair on the Public Switched Telephone Network (PSTN). V.92 improves the upstream data signaling rate and adds new features that enhance modem usability. These new modem protocols and standards are implemented at the modem level.

This feature module introduces the V.92 Modem on Hold feature on Cisco AS5350, Cisco AS5400, and Cisco AS5850 universal gateways and Cisco AS5800 universal access servers.

Note The other feature introduced with the new V.92 standard is V.92 Quick Connect, which is documented in the V.92 Quick Connect for Cisco AS5350, Cisco AS5400, and Cisco AS5850 Universal Gateways and Cisco AS5800 Universal Access Servers feature module. V.92 Modem On Hold and V.92 Quick Connect can be enabled independently of each other.

NextPort firmware provides V.92 capabilities bundled with existing NextPort features. The NextPort Dial Feature Card (DFC-108NP) is responsible for the ITU implementation of V.92 and the collection of statistics related to the new features, including the new Modem States that occur with the additional negotiations for V.92. The statistics are collected by the dial feature card (DFC) but are passed to and stored in Cisco IOS software. Cisco IOS software is responsible for controlling the features and displaying the new statistics.

The Cisco AS5800 uses the NextPort high density dial termination card to implement this feature. Both voice and dial technologies are supported when used in a Cisco 5850 universal gateway.

Note V.92 is packaged with V.44 in Cisco IOS software. For more information about V.44, refer to theV.44 LZJH Compression for Cisco AS5350, Cisco AS5400, and Cisco AS5850 Universal Gateways and Cisco AS5800 Universal Access Servers feature module.

Modem on Hold

V.92 Modem on Hold allows a dial-in customer to suspend a modem session to answer an incoming voice call or to place an outgoing call while engaged in a modem session. When the dial-in customer uses Modem on Hold to suspend an active modem session to engage in an incoming voice call, the Internet service provider (ISP) modem listens to the original modem connection and waits for the dial-in customer’s modem to resume the connection. When the voice call ends, the modem signals the telephone system to end the second call and return to the original modem connection, then the modem signals the ISP modem that it is ready to resume the modem call. Both modems renegotiate the connection, and the original exchange of data continues.

Note This feature is designed for use on telephone lines that are configured for call-waiting service; call-waiting signals trigger the suspension of the modem session. If call-waiting service is not present on the subscriber’s line, other callers receive a busy signal, and the modem session is not interrupted.

commands (modemcaps) or can be controlled on a per-caller basis using the RADIUS distributed client/server system.

Note You are not required to have a RADIUS server to use the Modem on Hold feature.

The following sections contain information about controlling the V.92 Modem on Hold feature:

- AT Commands (Modemcaps) and S-Registers

- RADIUS Authorization

AT Commands (Modemcaps) and S-Registers

lists additional S-register parameters used to enable and disable the feature.

To disable V.92 Modem on Hold, you can use a modemcap (for example, s62=0s63=3s21=15s29=12) or set the S29 register to any number other than 12. You can also use the RADIUS vendor-specific attribute (VSA) to disable Modem on Hold if the feature was initially enabled by the default value (modemcap).

Note If the feature is enabled using S29=12 and Modem on Hold is disabled using S62=0, statistics for the number of times a dial-in customer requests an on-hold are tracked in the MOH link information parameters. However, completely disabling the feature by setting S29 to a value other than 12 disables the reporting of all MOH statistics.

Table 1 V.92 Modem on Hold S-Registers

Name

Register

Index

Default

Description

Modem standard

S29

NextPort 0x8013

12 (V.92 enabled)

0 = V.34 Automode, without V.32ter

1 = V.34 Automode, without V.32ter

2 = V.32ter Automode

3 = V.32bis Automode

4 = V22bis Automode

5 = K56Flex

6 = V.90 Automode (V.92 builds only)

7 = (reserved)

8 = V.110

9 = (reserved)

10 = V.120

11 = Clear Channel

12 = V.92 Automode (V.92 builds only)

MOH timeout

S62

NextPort 0x803f

0

0: MOH disabled

1: 10 seconds

2: 20 seconds

3: 30 seconds

4: 40 seconds

5: 1 minute

6: 2 minutes

7: 3 minutes

8: 4 minutes

9: 6 minutes

10: 8 minutes

11: 12 minutes

12: 16 minutes

13: No limit

RADIUS Authorization

Modem on Hold attribute. You can enter the following value for this attribute:

- An unsigned integer in the range 0 through 65,535—Represents the maximum number of seconds that a modem may remain on hold, which can range from ten seconds to an unlimited number of minutes.

Note Although the integer attribute values can be specified as any value in a contiguous range, V.92 specifications limit configuration to a limited set of values. Attribute values are rounded down to the next permitted value when they are used to configure a modem.

keyword, which allows the modem to remain on hold indefinitely.

If the Modem on Hold configuration is not present, or if it is not syntactically correct, the modem uses its default configuration for Modem on Hold. The default operation can be modified by using a modemcap string. Following authentication of a dial-in user, an additional control command is sent to the modem if the dial-in user does not have a default Modem on Hold configuration.

Note Code space requirements for RADIUS support is less than 2KBs. There are no additional data space requirements.

V.92 Modem on Hold running on systems using RADIUS authorization increases the length of RADIUS response packets by approximately 20 bytes. RADIUS databases increase in size by approximately the same amount for each dial-in user with a nondefault Modem on Hold attribute value.

With RADIUS, authentication and authorization occur as part of the same process. When a caller connects to the access server, the caller enters a user ID and password in response to prompts from the access server. This information is formatted as a RADIUS request packet and is sent to the appropriate RADIUS server. If the user ID is valid and the password matches, the RADIUS server responds with a packet containing authorization data for the connection. This authorization data contains the Modem on Hold configuration if it is present in the RADIUS database.

The access server interprets the response from the RADIUS server and performs any actions associated with the authorization data. For Modem on Hold, a command is sent from the Cisco IOS host to the NextPort channel to set the Modem on Hold parameters. No confirmation from the channel is required.

When the client modem requests a Modem on Hold operation, the modem switches to an on-hold state, which prevents further data from being queued to the connection. When the Cisco IOS software receives the request to go on hold, any transmit packets queued to local Cisco IOS queues (packets not already posted to the queues shared between the Cisco IOS software and the modem) are discarded. This mechanism reduces the possibility that stale data will be transmitted to the modem when the connection is reactivated. It also reduces the number of buffer resources that are tied up while a modem is on hold.

Note When using a RADIUS server, placement of commas is important. The asterisk in the modem-on-hold attribute indicates that the attribute is optional. If a modem does not support Modem on Hold, then the call might continue anyway. If the asterisk is replaced by an “=”, the attribute is required, and modems that do not support Modem on Hold terminate the calls following authentication.

The value of the attribute is the number of seconds allowed for the on-hold state. This value is rounded by the Cisco IOS software to one of the permissible values. The number can be replaced with the inf command, which allows unlimited on-hold time. Case is significant for both attribute names and values.

Note If your router is configured for RADIUS, the RADIUS server must be accessible to the router. The server must also be capable of responding to authentication requests with VSA attributes.

Configuring V.92 Modem on Hold with RADIUS

If you use RADIUS to configure the Modem on Hold feature, use the modem-on-hold attribute, where the VALUE attribute is a nonnegative integer in seconds for maximum time on hold allowed. VALUE can be one of the following:

- modem-on-hold=VALUE—MOH support is required for call to be accepted.

- modem-on-hold*VALUE—MOH support is optional.

The following example shows RADIUS enabled where Modem on Hold is optional:

vendor-specific=9:1:modem-on-hold*VALUE

Note The examples shown below were established on the Cistron open-source server. Your server syntax may vary.

# This user can use MOH without time limits. (inf)

# MOH capability is not required for the connection (*)

testi Auth-Type = Local, Password = "test"

Service-Type = Login-User,

Cisco-AVPair = "modem-on-hold*inf"

# This user can use MOH for 30 seconds.

# MOH capability is not required for the connection.

test30 Auth-Type = Local, Password = "test"

Service-Type = Login-User,

Cisco-AVPair = "modem-on-hold*30"

# This user can not use MOH.

# MOH capability is not required for the connection.

test0 Auth-Type = Local, Password = "test"

Service-Type = Login-User,

Cisco-AVPair = "modem-on-hold*0"

# This user can not use MOH.

# But MOH capability IS required for the connection.

# If the user logs on to a device that does not support

# MOH (eg the console), he will be disconnected after

# authentication.

testr Auth-Type = Local, Password = "test"

Service-Type = Login-User,

Cisco-AVPair = "modem-on-hold=0"

# This user gets the default MOH setting.

# The default setting is disabled, unless overridden

# by a modemcap entry.

testx Auth-Type = Local, Password = "test"

Service-Type = Login-User

# This user can go on hold for 60 seconds

# in a PPP link. The service type determines

# which calls get the MOH setting.

lucy Auth-Type = Local, Password = "test"

Service-Type = Framed-User,

Cisco-AVPair = "modem-on-hold*60"

Note The service type defines when the AVPair is applied. For different RADIUS servers, the Cisco-AVPair syntax might be different, but the value in quotes does not change. Case is important: The entire text in quotes must be lowercase.

documentation.

Modem Enhancements for V.92 Modem On Hold

V.92 Modem on Hold feature:

- Disconnect Reasons

- Duration Limit Timer

- Modem on Hold Link Information Parameters

- Modem States

- New and Modified MIBs

Disconnect Reasons

lists the new Modem on Hold Disconnect Reasons.

Table 2 Modem On Hold Disconnect Reasons

Name

Description

DR_MOH_CLRD

Modem On Hold cleardown by modem

DR_MOH_TIMEOUT

Modem On Hold timeout value reached

Duration Limit Timer

The Modem on Hold duration limit timer is supported within dialed number ID service (DNIS), calling line ID (CLID), RADIUS (but not TACACS+), and global resource pool manager server (RPMS) virtual groups. This support permits ISPs to associate the Modem on Hold feature and its timer limit according to customer needs. When the Modem on Hold timer is active (a modem is on hold), it must take precedence over the idle timer. For example, if the idle value is five minutes and the Modem on Hold duration limit is ten minutes, the customer is permitted to be on another call for up to ten minutes without being disconnected after five minutes by the idle timer. The Modem on Hold timer value resets at the end of each on-hold session.

Modem on Hold Link Information Parameters

Table 3 Modem on Hold Link Information Parameters

Name

Description

MOH Status

0: Modem is not on hold

1: Modem is on hold

MOH Count

Number of times the modem is on hold

MOH Request Count

Number of times the modem received Modem on Hold requests.

Total MOH Time

Total holding time: 65,535 seconds maximum

Current MOH Time

Current holding time: 65,535 seconds maximum

Call Waiting Retrains

Number of times a retrain occurred due to a call-waiting signal

Modem States

This feature supports modem states, which are discrete states that a modem transitions through, during, and after negotiation with a client modem. These states include the Modem on Hold input state, the Steady input state, and the Steady, Steady Retrain, and Terminate output states.

New and Modified MIBs

Existing MIBs that show the status of modem settings have been extended to show V.92 Modem on Hold configuration status. New MIBs have been created to report the incidence of V.92 Modem on Hold request calls coming into the server and to monitor on-hold status.

Supported Module Firmware and Cisco IOS Software

V.92 Modem on Hold is supported on the following firmware and software:

- Module Firmware—The module firmware is a combination of modem (Digital Signal Processor or DSP) firmware and the module controller firmware. It is responsible for the collection of statistics and the actual implementation of V.92, including additional required state transitions.

- Cisco IOS software—The Cisco IOS software is responsible for the control and statistics reporting of the new features, including modemcaps, RADIUS authorization, and command-line interface (CLI) support. See the “Related Documents” section for information about new Cisco IOS Release features.

Benefits

Allows Voice Calls Without Interruption of Existing Modem Connection

V.92 Modem on Hold allows the origination and reception of voice calls without disturbing preexisting modem sessions. With Modem on Hold, calls can ring through to the dial-in user without requiring the expense of a second telephone line.

Per-Use Enabling

Service providers can enable Modem on Hold on a per-user basis for premium service opportunities.

Standard Modem Feature

V.92 is a standard modem feature that is offered as a no-cost upgrade to the installed system.

V.92 Compatibility

Modems that support V.92 are fully compatible with modems that do not support it. If a modem that supports Modem on Hold connects with a modem that does not support it, the modems will connect normally. However, the Modem on Hold function is not available for that call.

Restrictions

- Client modem vendors must supply their own utilities to enable Modem on Hold with each client modem.

- There is no standard method for notifying remote or user applications that a modem session has been placed on hold. Extending timeouts or increasing the maximum number of attempts to perform certain operations might be necessary. No e-mail data should be lost because of on-hold times.

- When a Modem on Hold transaction returns to the data-connected state, it retains the same IP network connection. Any other connected applications might not be returned to their prior state, depending on the application’s data transaction requirements during the Modem on Hold active state.

- Configuration of these features using S-registers is carried out by using modemcaps ( AT commands). Cisco IOS software does not check these values to guarantee that they are valid. The behavior of invalid values is determined by the module.

- Authorization of Modem on Hold is not provided as a standard service by RADIUS. However, RADIUS provides a vendor-specific attribute (VSA) capability that can be used to extend authorization mechanisms. This capability is already used by Cisco routers to provide other custom services.

- Cisco IOS software is packaged as multiple program image types with varying capabilities. Because not all modem interfaces support Modem on Hold and because images may be built to support specific modem types, not all software images contain functions to control Modem on Hold. In addition, the modems that do support Modem on Hold implement their control functions differently. Therefore, registry functions are used to interface between RADIUS, local authorization, and Modem on Hold control for modems.

- Server-initiated Modem on Hold is not supported

- During a suspended modem session, some data might be dropped. The ISP idle timer, which disconnects a dial-in user if there is no data exchanged for a period of time, should be reset and suspended while a connection is on hold.

Note Many client modems used in Europe are known to have problems with the Modem on Hold feature. The vendors are aware of the issue and are working to correct it. If you are having trouble with the Modem on Hold feature in Europe, it is suggested that the customer contact the client modem vendor to verify that the modem complies with the telephony signaling for call waiting, caller ID, and 3-way calling in their particular country.

Related Features and Technologies

- V.92 Quick Connect

- V.44 LZJH data compression service

- Mindspeed CSMv6 hardware solution

Related Documents

- AT Command Set and Register Summary for NextPort Platforms

- Cisco AS5350 documentation index

- Cisco AS5400 documentation index

- Cisco AS5800 documentation index

- Cisco AS5850 documentation index

- Cisco AS5800 Universal Access Server Release Notes

- Cisco IOS Release 12.2 Master Indexes

- Comparing NextPort SPE Commands to MICA Modem Commands

- Managing Port Services on the Cisco AS5400 Universal Gateway

- Managing and Troubleshooting the NextPort Dial Feature Card

- New Features in Release 12.2(2)XB

- NextPort Port Service Management for the Cisco AS5400 Universal Gateway

- Release Notes for Cisco AS5350 Universal Gateways for Cisco IOS Release 12.2 XA

- Release Notes for Cisco AS5350 and AS5350HPX Universal Gateways for Cisco IOS Release 12.2 XB

- Cisco IOS Release 12.2T Cross-Platform Release Notes

- SPE and Firmware Download Enhancements

- V.44 LZJH Compression for Cisco AS5350 and Cisco AS5400 Universal Gateways

- V.92 Quick Connect for Cisco AS5350 and Cisco AS5400 Universal Gateways

Supported Platforms

- Cisco AS5350

- Cisco AS5400

- Cisco AS5800

- Cisco AS5850

Table 4 Cisco IOS Release and Platform Support for this Feature

Platform

12.2(2)XA

12.2(2)XB1

12.2(11)T

Cisco AS5350

X

X

X

Cisco AS5400

X

X

X

Cisco AS5800

Not supported

X

X

Cisco AS5850

Not supported

X

X

Determining Platform Support Through Cisco Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Cisco Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.

.

Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:

Availability of Cisco IOS Software Images

Platform support for particular Cisco IOS software releases is dependent on the availability of the software images for those platforms. Software images for some platforms may be deferred, delayed, or changed without prior notice. For updated information about platform support and availability of software images for each Cisco IOS software release, refer to the online release notes or, if supported, Cisco Feature Navigator.

Supported Standards, MIBs, and RFCs

Standards

- V.44

- V.92 Modem on Hold

- V.92 Quick Connect

MIBs

- CISCO-MODEM-MGMT-MIB

- CISCO-CALL-TRACKER-MODEM-MIB

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

If Cisco MIB Locator does not support the MIB information that you need, you can also obtain a list of supported MIBs and download MIBs from the Cisco MIBs page at the following URL:

To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:

RFCs

No new or changed RFCs are supported by this feature.

Prerequisites

- Cisco IOS Release 12.2(2)XB1 or 12.2(11)T.

- Minimum of 32K memory needed for bundled Cisco NextPort firmware

- Additional data space needed on the modem module (refer to Cisco NextPort documentation)

- Basic configuration of the Cisco AS5350, Cisco AS5400, Cisco AS5800, or Cisco AS5850

- Upgraded modem firmware

- NextPort DFC installed

- Modems must be capable of supporting Modem on Hold

Configuration Tasks

None

For additional information, refer to the following documents:

- V.44 LZJH Compression for Cisco AS5350, Cisco AS5400, and Cisco AS5850 Universal Gateways and Cisco AS5800 Universal Access Servers

- V.92 Quick Connect for Cisco AS5350, Cisco AS5400, and Cisco AS5850 Universal Gateways and Cisco AS5800 Universal Access Servers

Monitoring and Maintaining Modem on Hold

Use the following show commands in privileged EXEC mode.

Command

Purpose

Displays the modem service statistics of all active calls on specified service processing elements (SPEs).

Router# show spe modem disconnect-reason

Displays the digital disconnect reasons for the specified SPE or SPE range.

Displays the operational status of the specified ports or the specified port range.

Displays the event log with oldest event first.

Displays the configuration information for specified ports or the specified port range.

Displays the call success rate (CSR) for the specified SPEs.

Displays the modem service history statistics for specified SPEs.

Displays the port level information stored within the Call Tracker active database for all active modem calls.

Configuration Examples

None

Command Reference

.

- show call calltracker active

- show port configuration

- show port modem log

- show port operational-status

- show spe modem active

- show spe modem csr

- show spe modem disconnect-reason

- show spe modem summary

Glossary

—command-line interface.

—Mindspeed modem hardware solution.

—call success rate.

—dial feature card.

—Digital Signal Processor. Microprocessor on which the modulation/demodulation process is carried out.

—Internet service provider.

—International Telecommunication Union Telecommunication Standardization Sector.

—Lempel-Ziv-Jeff-Heath data compression algorithm used in V.44.

—Modem ISDN channel aggregation. Used as a generic term to describe the Dial Technology Division (DTD) high-density modem technology.

—Modem on Hold functionality specified in V.92.

—Device driver architecture for Cisco IOS software that supports the NextPort hardware and software interfaces. Supports the Universal Port concept.

—pulse code modulation.

—Point-to-Point Protocol.

—Public Switched Telephone Network.

—service processing element.

—Concept of a single device that can terminate one digital signaling level zero (DS0) with a data modem, fax modem, ISDN, or voice solution.

—Quick Connect functionality specified in V.92.

—ITU modem standard for LZJH data compression algorithm.

—ITU modem standard that contains Quick Connect and Modem On Hold.

—vendor specific attribute (RADIUS).

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001-2009 Cisco Systems, Inc. All rights reserved.

V.92 Quick Connect for Cisco AS5300 and Cisco AS5800 Universal Access Servers

Feature History

Release

Modification

12.2(2)XA

This feature was introduced on the Cisco AS5350 and Cisco AS5400 running NextPort firmware.

Note As of July 18, 2001, this feature was introduced on the Cisco AS5300 running Cisco MICA Portware Version 2.9.1.0.

12.2(2)XB

This feature was supported with Cisco IOS Release 12.2(2)XB.

12.2(2)XB1

This feature was supported on Cisco AS5800.

12.2(11)T

This feature was integrated into Cisco IOS Release 12.2(11)T and support was added for the Cisco AS5300 and Cisco AS5800 platforms.

This feature module describes the V.92 International Telecommunication Union Telecommunication Standardization Sector (ITU-T) standard Quick Connect (QC) feature with Cisco MICA portware platforms using Cisco IOS Software Releases 12.2(2)XB1 and 12.2(11)T.

This document includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Prerequisites

- Configuration Tasks

- Configuration Examples

- Command Reference

- Glossary

Feature Overview

V.92

To remain current with industry needs, the ITU-T V.90 modem standard recommendations have been enhanced. The new standard, V.92, meets the need for a digital modem and analog modem pair on the Public Switched Telephone Network (PSTN). V.92 improves the upstream data signaling rate and adds new features that enhance modem usability. These new modem protocols and standards are implemented at the modem level.

This feature module introduces the V.92 Quick Connect feature on Cisco AS5300 and Cisco AS5800 universal access servers with Cisco MICA Portware Version 2.9.1.0.

Note The other feature introduced with the new V.92 standard is V.92 Modem on Hold, which is documented in the V.92 Modem on Hold for Cisco AS5300 and Cisco AS5800 Universal Access Servers feature module. V.92 Modem On Hold and V.92 Quick Connect can be enabled independently of each other.

V.92 is implemented at the modem level as new modem protocols and standards. The new V.92 features co-reside with existing portware features and have no impact on the hardware configuration of either the Hex Modem Module (HMM) or Double Density Modem Module (DMM), including memory requirements. Cisco IOS software is responsible for controlling the features and displaying the new statistics. V.92 and V.44 support is bound with the rest of the Cisco IOS device driver components.

Note V.92 and V.44 are packaged together with Cisco IOS software. For more information about V.44, refer to the V.44 LZJH Compression for Cisco AS5300 and Cisco AS5800 Universal Access Servers feature module.

Note This feature does not support pulse code modulation (PCM) upstream as defined in the V.92 ITU standard. This feature does, however, interoperate with modems that support PCM upstream.

Quick Connect

V.92 Quick Connect speeds up the client-to-server startup negotiation, reducing the overall connect time up to 30 percent. The client modem retains line condition information and characteristics of the connection to the Internet service provider (ISP), which reduces connect time by avoiding some of the initial signal handshaking.

lists the new link information parameters.

Table 1 Quick Connect States

Name

Description

Quick Connect

Phase 1 V.92 Quick Connect is being negotiated.

Steady QC

V.92 Quick Connect is being used to reconnect after a V.92 Modem on Hold exchange.

V.8bis Exchange

A V.8bis exchange is taking place.

Ranging

A full phase 2 trainup is taking place.

Ranging Short

A shortened phase 2, using V.92 Quick Connect, is taking place.

Half Duplex Train

Adaptive equalizer training has begun.

Table 2 Quick Connect Link Information Parameters

Name

Value

QC Exchange

0: No QC

1: QC Requested

2: QC Short Train Fail

3: QC Full Train Success

4: QC Short Train Success

AT Commands and S-Registers

commands are used to configure V.92 Quick Connect on Cisco MICA platforms.

lists the S-registers used to enable and disable the V.92 Quick Connect feature.

,

Table 3 Configuring V.92 Quick Connect with S-Registers

Name

Register

Index

Default

Description

V.92 QC Configuration

S63

MICA 64

0x3

QC Enabled

ANSpcm Level –12 dBm

Bit 0: QC Enabled

0: Disabled

1: Enabled

Bits 1–2 ANSpcm Level

00: –9 dBm

01: –12 dBm

10: –15 dBm

11: –18 dBm

S29

MICA 19

12 (V.92 enabled)

0 = V.34bis Automode, with V.32ter

1 = V.34bis Automode, without V.32ter

2 = reserved

3 = V.32bis Automode

4 = V22bis Automode

5 = K56Flex 1.1 Automode

6 = V.90 Automode

7 = MICA:SS7/COT

8 = V.110

9 = Reserved

10 = Reserved

11 = Reserved

12 = V.92 Auto-mode

Note If the V.92 Quick Connect feature is enabled using S29=12, and QC is disabled using S63=0, then the QC Exchange Link Information Parameter is updated to show if QC was requested. However, completely disabling the feature by setting S29 to a value other than 12 disables the reporting of QC requests.

.

Benefits

Improved Port Use

This feature improves ISP port usage because of the reduction in connect time.

Standard Modem Feature

V.92 is a standard modem feature that is offered as a no-cost upgrade to the installed system.

Restrictions

- Configuration of these features using S-registers is carried out by using modemcaps ( AT commands). Cisco IOS software does not check these values to guarantee that they are valid. The behavior of invalid values is determined by the module.

- Cisco IOS software is packaged as multiple program image types with varying capabilities. Because not all modem interfaces support Quick Connect and because images may be built to support specific modem types, not all software images contain functions to control Quick Connect. In addition, the modems that do support Quick Connect implement their control functions differently. Therefore, registry functions are used to interface between local authorization and Quick Connect control for modems.

Related Features and Technologies

- V.92 Modem on Hold

- V.44 LZJH data compression service

- Mindspeed CSMv6 hardware solution

Related Documents

- AT Command Set and Register Summary for MICA Six-Port Modules

- Call Tracker plus ISDN and AAA Enhancements for the Cisco AS5300

- Cisco AS5300 documentation index

- Cisco AS5800 documentation index

- Cisco IOS Release 12.2 Master Indexes

- Release Notes for Cisco AS5300 Universal Access Servers, Cisco IOS Release 12.2(2)XA

- Release Notes for Cisco AS5300 Universal Access Servers, Cisco IOS Release 12.2(2)XB

- Cisco IOS Release 12.2T Cross-Platform Release Notes

- Cisco AS5800 Universal Access Server Release Notes

- Comparing NextPort SPE Commands to MICA Modem Commands

- Release Notes for Cisco MICA Portware Version 2.9.1.0 on Cisco AS5300 Universal Access Servers

- New Features in Release 12.2(2)XB

- SPE and Firmware Download Enhancements

- V.44 LZJH Compression for Cisco AS5300 and Cisco AS5800 Universal Access Servers

- V.92 Modem on Hold for Cisco AS5300 and Cisco AS5800 Universal Access Servers

Supported Platforms

This feature is supported on the following Cisco platforms:

- Cisco AS5300

- Cisco AS5800

Table 4 Cisco IOS Release and Platform Support for this Feature

Platform

12.2(2)XA

12.2(2)XB

12.2(2)XB1

12.2(2)XB1

Cisco AS5300

X

X

X

X

Cisco AS5800

Not supported

Not supported

X

X

Determining Platform Support Through Cisco Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Cisco Feature Navigator is a web-based tool that enables you to determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.

Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:

Availability of Cisco IOS Software Images

Platform support for particular Cisco IOS software releases is dependent on the availability of the software images for those platforms. Software images for some platforms may be deferred, delayed, or changed without prior notice. For updated information about platform support and availability of software images for each Cisco IOS software release, refer to the online release notes or, if supported, Cisco Feature Navigator.

Supported Standards, MIBs, and RFCs

Standards

- V.44

- V.92 Modem on Hold

- V.92 Quick Connect

MIBs

- CISCO-MODEM-MGMT-MIB

- CISCO-CALL-TRACKER-MODEM-MIB

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

If Cisco MIB Locator does not support the MIB information that you need, you can also obtain a list of supported MIBs and download MIBs from the Cisco MIBs page at the following URL:

To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:

RFCs

No new or changed RFCs are supported by this feature.

Prerequisites

- Cisco IOS Release 12.2(2)XA, 12.2(2)XB, or 12.2(11)T

- Basic configuration of the Cisco AS5300 or Cisco AS5800

- Upgraded modem firmware (Cisco MICA portware 2.9.1.0)

Configuration Tasks

None

Configuration Examples

None

Command Reference

.

Also see the following documentation for further information about V.92 and V.44 using Cisco MICA technology:

- V.44 LZJH Compression for Cisco AS5300 and Cisco AS5800 Universal Access Servers

- V.92 Modem on Hold for Cisco AS5300 and Cisco AS5800 Universal Access Servers

Glossary

—command-line interface.

—Mindspeed modem hardware solution.

—call success rate.

—dial feature card.

—Digital Signal Processor. Microprocessor on which the modulation/demodulation process is carried out.

—Internet service provider.

—International Telecommunication Union Telecommunication Standardization Sector.

—Lempel-Ziv-Jeff-Heath data compression algorithm used in V.44.

—Multi-service IOS Channel Aggregation. Used as a generic term to describe the Dial Technology Division (DTD) high density modem technology.

—Modem on Hold functionality specified in V.92.

—Device driver architecture for Cisco IOS software that supports the NextPort hardware and software interfaces. Supports the universal port concept.

—pulse code modulation.

—Public Switched Telephone Network.

—Remote Dial-In User Service. Database for authenticating modem and ISDN connections and for tracking connection time.

—service processing element.

—Quick Connect functionality specified in V.92

—Concept of a single device that can terminate one digital signaling level zero (DS0) with a data modem, fax modem, ISDN, or voice solution.

—ITU modem standard for LZJH data compression algorithm.

—ITU modem standard that contains Quick Connect, Modem On Hold, and PCM upstream.

—vendor specific attribute (as used with RADUIS).

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001–2009 Cisco Systems, Inc. All rights reserved.

V.92 Quick Connect for Cisco AS5350, Cisco AS5400, and Cisco AS5850 Universal Gateways and Cisco AS5800 Universal Access Servers

Feature History

Release

Modification

12.2(2)XA1 and 2

This feature was introduced on Cisco AS5350 and Cisco AS5400 universal gateways running NextPort firmware.

12.2(2)XB1 and 2

This feature was supported with Cisco IOS Software Release 12.2(2)XB1 and 2.

12.2(11)T

This feature was integrated into Cisco IOS Release 12.2(11)T and support was added for the Cisco AS5350, Cisco AS5400, Cisco AS5800, and Cisco AS5850 platforms.

This feature module introduces the V.92 International Telecommunication Union Telecommunication Standardization Sector (ITU-T) standard Quick Connect (QC) feature on NextPort/DFC108-bearing platforms using Cisco IOS Software Releases 12.2(2)XA, 12.2(2)XB, and 12.2(11)T.

This document includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Prerequisites

- Configuration Tasks

- Configuration Examples

- Command Reference

- Glossary

Feature Overview

V.92

To remain current with industry needs, the ITU-T V.90 modem standard recommendations have been enhanced. The new standard, V.92, meets the need for a digital modem and analog modem pair on the Public Switched Telephone Network (PSTN). V.92 improves the upstream data signaling rate and adds new features that enhance modem usability. These new modem protocols and standards are implemented at the modem level.

This feature module introduces the V.92 Quick Connect feature on Cisco AS5350, Cisco AS5400, and Cisco AS5850 universal gateways and Cisco AS5800 universal access servers.

Note The other feature introduced with the new V.92 standard is V.92 Modem on Hold, which is documented in the V.92 Modem on Hold for Cisco AS5350, Cisco AS5400, and Cisco AS5850 Universal Gateways and Cisco AS5800 Universal Access Servers feature module. V.92 Modem On Hold and V.92 Quick Connect can be enabled independently of each other.

V.92 provides new modem protocols and standards that are implemented at the modem level.

NextPort firmware provides V.92 capabilities bundled with existing NextPort features. The NextPort Dial Feature Card (DFC-108NP) is responsible for the ITU implementation of V.92 and the collection of statistics related to the new features, including the new modem states that occur with the additional negotiations for V.92. The statistics are collected by the DFC but are passed to and stored in Cisco IOS software. Cisco IOS software is responsible for controlling the features and displaying the new statistics.

The Cisco AS5800 uses the NextPort high density dial termination card to implement this feature. Both voice and dial technologies are supported when used in a Cisco 5850 universal gateway.

Note V.92 and V.44 are packaged together with Cisco IOS software. For more information about V.44, refer to the V.44 LZJH Compression for Cisco AS5350, Cisco AS5400, and Cisco AS5850 Universal Gateways and Cisco AS5800 Universal Access Server feature module.

Quick Connect

V.92 Quick Connect speeds up the client-to-server startup negotiation, reducing the overall connect time up to 30 percent. The client modem retains line condition information and characteristics of the connection to the Internet service provider (ISP), which reduces connect time by avoiding some of the initial signal handshaking.

lists the new link information parameters.

Table 1 Quick Connect States

Name

Description

Quick Connect

Phase 1 V.92 Quick Connect is being negotiated.

Steady QC

V.92 Quick Connect is being used to reconnect after a V.92 Modem on Hold exchange.

V.8bis Exchange

A V.8bis exchange is taking place.

Ranging

A full phase 2 trainup is taking place.

Ranging Short

A shortened phase 2, using V.92 Quick Connect, is taking place.

Half Duplex Train

Adaptive equalizer training has begun.

Table 2 Quick Connect Link Information Parameters

Name

Value

QC Exchange

0: No QC

1: QC Requested

2: QC Short Train Fail

3: QC Full Train Success

4: QC Short Train Success

AT Commands and S-Registers

commands are used to configure V.92 Quick Connect on NextPort platforms.

lists the S-registers used to enable and disable the V.92 Quick Connect feature.

,

Table 3 Configuring V.92 Quick Connect with S-Registers

Name

Register

Index

Default

Description

V.92 QC Configuration

S63

NextPort 0x8040

0x3

QC Enabled

ANSpcm Level –12 dBm

Bit 0: QC Enabled

0: Disabled

1: Enabled

Bits 1–2 ANSpcm Level

00: –9 dBm

01: –12 dBm

10: –15 dBm

11: –18 dBm

S29

NextPort 0x8013

12 (V.92 enabled)

0 = V.34 Automode, without V.32ter

1 = V.34 Automode, without V.32ter

2 = V.32ter Automode

3 = V.32bis Automode

4 = V22bis Automode

5 = K56Flex

6 = V.90 Automode (V.92 builds only)

7 = (reserved)

8 = V.110

9 = (reserved)

10 = V.120

11 = Clear Channel

12 = V.92 Automode (V.92 builds only)

Note If the V.92 Quick Connect feature is enabled using S29=12, and QC is disabled using S63=0, then the QC Exchange Link Information Parameter is updated to show if QC was requested. However, completely disabling the feature by setting S29 to a value other than 12 disables the reporting of QC requests.

For detailed information about the AT commands and S-registers that are used to configure the V.92 Quick Connect feature supported by NextPort services, refer to the AT Command Set and Register Summary for NextPort Platforms.

Benefits

Improved Port Use

This feature improves ISP port usage because of the reduction in connect time.

Standard Modem Feature

V.92 is a standard modem feature that is offered as a no-cost upgrade to the installed system.

Restrictions

- Minimum of 32K memory is needed for bundled NextPort firmware.

- Additional data space is needed on the modem module (refer to NextPort documentation).

- Configuration of these features using S-registers is carried out by using modemcaps ( AT commands). Cisco IOS software does not check these values to guarantee that they are valid.

- Cisco IOS software is packaged as multiple program image types with varying capabilities. Because not all modem interfaces support Quick Connect and because images may be built to support specific modem types, not all software images contain functions to control Quick Connect. In addition, the modems that do support Quick Connect implement their control functions differently. Therefore, registry functions are used to interface between local authorization and Quick Connect control for modems.

Related Features and Technologies

- V.92 Modem on Hold

- V.44 LZJH data compression service

- Mindspeed CSMv6 hardware solution

Related Documents

- AT Command Set and Register Summary for NextPort Platforms

- Cisco AS5350 documentation index

- Cisco AS5400 documentation index

- Cisco AS5800 documentation index

- Cisco AS5850 documentation index

- Comparing NextPort SPE Commands to MICA Modem Commands

- Managing and Troubleshooting the NextPort Dial Feature Card

- NextPort Port Service Management for the Cisco AS5400 Universal Gateways

- V.92 Modem on Hold for Cisco AS5350 and Cisco AS5400 Universal Gateways

Supported Platforms

- Cisco AS5350

- Cisco AS5400

- Cisco AS5800

- Cisco AS5850

Table 4 Cisco IOS Release and Platform Support for this Feature

Platform

12.2(2)XA

12.2(2)XB

12.2(2)XB1

12.2(11)T

Cisco AS5350

X

X

X

X

Cisco AS5400

X

X

X

X

Cisco AS5800

Not supported

Not supported

X

X

Cisco AS5850

Not supported

Not supported

X

X

Determining Platform Support Through Cisco Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Cisco Feature Navigator is a web-based tool that enables you to determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.

.

Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:

Availability of Cisco IOS Software Images

Platform support for particular Cisco IOS software releases is dependent on the availability of the software images for those platforms. Software images for some platforms may be deferred, delayed, or changed without prior notice. For updated information about platform support and availability of software images for each Cisco IOS software release, refer to the online release notes or, if supported, Cisco Feature Navigator.

Supported Standards, MIBs, and RFCs

Standards

- V.44

- V.92 Modem on Hold

- V.92 Quick Connect

MIBs

- CISCO-MODEM-MGMT-MIB

- CISCO-CALL-TRACKER-MODEM-MIB

RFCs

No new or changed RFCs are supported by this feature.

Prerequisites

- Cisco IOS Release 12.2(2)XA, 12.2(2)XB, or 12.2(11)T

- Minimum of 32K memory needed for bundled Cisco NextPort firmware

- Additional data space needed on the modem module (refer to NextPort documentation)

- Basic configuration of the Cisco AS5350, Cisco AS5400, Cisco AS5850, or Cisco AS5800

- Upgraded modem firmware

- NextPort DFC installed

Configuration Tasks

None

For information about configuration, refer to the following documents:

- V.92 Modem on Hold for Cisco AS5350, Cisco AS5400, and Cisco AS5850 Universal Gateways and Cisco AS5800 Universal Access Servers

- V.92 Quick Connect for Cisco AS5300 and Cisco AS5800 Universal Access Servers

Configuration Examples

None

Command Reference

.

Glossary

—command-line interface.

—Mindspeed modem hardware solution.

—dial feature card.

—Digital Signal Processor. Microprocessor on which the modulation/demodulation process is carried out.

—Internet service provider.

—International Telecommunication Union Telecommunication Standardization Sector.

—Lempel-Ziv-Jeff-Heath data compression algorithm used in V.44.

—Modem on Hold functionality specified in V.92.

—Device driver architecture for Cisco IOS software that supports the NextPort hardware and software interfaces. Supports the universal port concept.

—pulse code modulation.

—Public Switched Telephone Network.

—Quick Connect functionality specified in V.92.

—Concept of a single device that can terminate one digital signaling level zero (DS-0) with a data modem, fax modem, ISDN, or voice solution.

—ITU modem standard for LZJH data compression algorithm.

—ITU modem standard that contains Quick Connect and Modem On Hold.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001–2009 Cisco Systems, Inc. All rights reserved.

V.92 Reporting Using RADIUS Attribute v.92-info

The V.92 Reporting Using RADIUS Attribute v.92-info feature provides the ability to track V.92 call information, such as V.92 features that are supported, the Quick Connect feature set that was attempted, the duration for which the original call was put on hold, and how many times Modem On Hold was initiated. The vendor-specific attribute (VSA) v.92-info is included in accounting “start” and “stop” records when modems negotiate a V.92 connection.

Feature Specifications for the V.92 Reporting Using RADIUS Attribute v.92-info Feature

Feature History

Release

Modification

12.3(1)

This feature was introduced.

Supported Platforms

Cisco AS5300, Cisco AS5350, Cisco AS5400, Cisco AS5800, Cisco AS5850

Finding Support Information for Platforms and Cisco IOS Software Images

at the login dialog box and follow the instructions that appear.

Contents

- Prerequisites for V.92 Reporting Using RADIUS Attribute v.92-info

- Restrictions for V.92 Reporting Using RADIUS Attribute v.92-info

- Information About V.92 Reporting Using RADIUS Attribute v.92-info

- Monitoring V.92 Call Information

- Verifying V.92 Call Information

- Additional References

- Command Reference

Prerequisites for V.92 Reporting Using RADIUS

Attribute v.92-info

Before the network access server (NAS) can send attribute v.92-info information in accounting “start” and “stop” records, you must perform the following tasks:

- Configure your NAS for authentication, authorization, and accounting (AAA) and to accept incoming modem calls.

- Enable AAA accounting by using the aaa accounting network default start-stop group radius command in global configuration mode.

- Familiarize yourself with the V.92 Quick Connect feature. Refer to the following document:

- Familiarize yourself with the V.92 Modem on Hold feature. Refer to the following document:

Restrictions for V.92 Reporting Using RADIUS Attribute v.92-info

- If V.92 is not negotiated on your server, V.92 information will not be included in the accounting record.

- Because the attribute v.92-info information is sent as a Cisco VSA, if you configure your RADIUS server as nonstandard (using a non-Cisco server), the V.92 call information will not be sent by default. However, you can still get the V.92 call information by first configuring the radius-server vsa send command with the accounting keyword (that is, radius-server vsa send accounting ).

Information About V.92 Reporting Using RADIUS Attribute v.92-info

Before you use the V.92 Reporting Using RADIUS Attribute v.92-info feature, you must understand the following concepts:

- V.92 Standard Overview

- VSA v.92-info

V.92 Standard Overview

The International Telecommunication Union Telecommunication Standardization Sector (ITU-T) V.92 standard encompasses a number of specifications, including Quick Connect (QC), which dramatically improves how quickly users can connect with their Internet service provider (ISP), and Modem on Hold (MoH), which enables users to suspend and reactivate their dial-up connection to either receive or initiate a telephone call. V.92 also includes pulse code modulation (PCM) upstream, which boosts the upstream data rates from the user to the ISP to reduce transfer times for large files and e-mail attachments sent by the user.

VSA v.92-info

The VSA v.92-info information in RADIUS accounting “start” and “stop” records can help you track V.92 feature set information. The VSA is enabled by default for all sessions that reside over a modem call that is connected using V.92 model modulation.

The VSA information is displayed in the “start” and “stop” records as follows:

v92-info=<V.92 features supported>/<QC Exchange>/<Total MOH time>/<MOH count>

The VSA v92-info has the following four subfields:

- V.92 features supported—All features that are available for the V.92 modem user who is dialing in. These features include QC, MoH, and PCM Upstream.

- QC Exchange—If QC was initiated, this subfield states what feature set (within QC) was attempted.

- Total MOH time—If MoH was initiated, this subfield indicates the duration for which the original call was put on hold.

- MOH count—If MOH was initiated, this field indicates how many times the MOH was initiated.

The following is an example of VSA v92-info information displayed in an accounting record:

v92-info=V.92 QC MOH/QC Requested/60/1

How to Monitor and Verify V.92 Call Information

The following sections include tasks to help you monitor and verify V.92 call information:

- Monitoring V.92 Call Information

- Verifying V.92 Call Information

Monitoring V.92 Call Information

To monitor the V.92 information in the accounting “start” and “stop” records, you can perform the following task using some or all of the debug commands that are listed:

SUMMARY

4. debug aaa authorization

5. debug isdn event

7. debug ppp {negotiation | authentication}

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# debug aaa accounting

Displays information about accountable events as they occur.

Step 3

Router# debug aaa authentication

Displays information about AAA authentication.

Step 4

Router# debug aaa authorization

Displays information about AAA and TACACS+ authorization.

Step 5

debug isdn event

Router# debug isdn event

Displays ISDN events occurring on the user side (on the router) of the ISDN interface.

Step 6

]

Router# debug modem csm 1/0 group 1

Displays call switching module (CSM) modem call information.

Step 7

}

Router# debug ppp authentication

Displays information on traffic and exchanges in an internetwork that is implementing the PPP.

Step 8

Router# debug radius

Displays information associated with RADIUS.

Examples

The following sample debug outputs display information about a V.92 reporting situation:

Debug Output 1

01:39:19: ISDN Se7/6:23: RX <- SETUP pd = 8 callref = 0x42A0

01:39:19: Bearer Capability i = 0x9090A2

01:39:19: Channel ID i = 0xA18396

01:39:19: Progress Ind i = 0x8183 - Origination address is non-ISDN

01:39:19: Calling Party Number i = 0xA1, '60112', Plan:ISDN, Type:National

01:39:19: Called Party Number i = 0xA1, '50138', Plan:ISDN, Type:National

01:39:19: Locking Shift to Codeset 6

01:39:19: Codeset 6 IE 0x28 i = 'ANALOG,savitha'

01:39:19: ISDN Se7/6:23: Incoming call id = 0x0038, dsl 0

01:39:19: ISDN Se7/6:23: NegotiateBchan: bchan 22 intid 0 serv_st 0 chan_st 0 callid 0x0000 ev 0x90 n/w? 0

01:39:19: Negotiated int_id 0 bchan 0 cr=0xC2A0 callid=0x0038 lo_chan 22 final int_id/bchan 0/22 cause 0x0

01:39:19: ISDN Se7/6:23: LIF_EVENT: ces/callid 1/0x38 CALL_INCOMING

01:39:19: ISDN Se7/6:23: CALL_INCOMING dsl 0 bchan 21

01:39:19: voice_parse_intf_name: Using the old NAS_PORT string

01:39:19: AAA/ACCT/EVENT/(00000007): CALL START

01:39:19: AAA/ACCT(00000000): add node, session 9

01:39:19: AAA/ACCT/NET(00000007): add, count 1

01:39:19: AAA/ACCT/EVENT/(00000007): ATTR REPLACE

01:39:19: ISDN Se7/6:23: CALL_INCOMING: call type is VOICE ULAW, bchan = 21

01:39:19: ISDN Se7/6:23: Event: Received a VOICE call from 60112 on B21 at 64 Kb/s Tone Value 0

01:39:19: AAA/ACCT/DS0: channel=21, ds1=6, t3=0, slot=7, ds0=117465109

01:39:19: AAA/ACCT/DS0: channel=21, ds1=6, t3=0, slot=7, ds0=117465109

01:39:19: VDEV_ALLOCATE: 1/5 is allocated

01:39:19: ISDN Se7/6:23: RM returned call_type 1 resource type 0 response 2

01:39:19: EVENT_FROM_ISDN: dchan_idb=0x63B3D334, call_id=0x38, ces=0x0

bchan=0x15, event=0x1, cause=0x0

01:39:19: dev in call to isdn : set dnis_collected & fap_notify

01:39:19: EVENT_FROM_ISDN:(0038): DEV_INCALL at slot 1 and port 5

01:39:19: EVENT_FROM_ISDN: decode:calling oct3 0xA1, called oct3 0xA1, oct3a 0x0,mask 0x3D

01:39:19: EVENT_FROM_ISDN: csm_call_info:calling oct3 0xA1, called oct3 0xA1, oct3a 0x0,mask 0x3D

01:39:19: CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 5

01:39:19: CSM DSPLIB(1/5/csm_flags=0x12): np_dsplib_prepare_modem

01:39:19: csm_connect_pri_vdev: TS allocated at bp_stream 0, bp_Ch 5, vdev_common 0x62EAD8F4 1/5

01:39:19: ISDN Se7/6:23: EVENT to CSM:DEV_INCALL: calltype=VOICE, bchan=21

01:39:19: ISDN Se7/6:23: TX -> CALL_PROC pd = 8 callref = 0xC2A0

01:39:19: Channel ID i = 0xA98396

01:39:19: ISDN Se7/6:23: TX -> ALERTING pd = 8 callref = 0xC2A0

01:39:19: CSM DSPLIB(1/5):DSPLIB_MODEM_INIT: Modem session transition to IDLE

01:39:19: CSM DSPLIB(1/5): Modem went offhook

01:39:19: CSM_PROC_IC2_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 5

01:39:19: ISDN Se7/6:23: VOICE_ANS Event: call id 0x38, bchan 21, ces 0

01:39:19: ISDN Se7/6:23: isdn_send_connect(): msg 74, call id 0x38, ces 0 bchan 21, call type VOICE

01:39:19: ISDN Se7/6:23: TX -> CONNECT pd = 8 callref = 0xC2A0

01:39:19: ISDN Se7/6:23: RX <- CONNECT_ACK pd = 8 callref = 0x42A0

01:39:19: ISDN Se7/6:23: LIF_EVENT: ces/callid 1/0x38 CALL_PROGRESS

01:39:19: ISDN Se7/6:23: event CALL_PROGRESS dsl 0

01:39:19: ISDN Se7/6:23: CALL_PROGRESS: CALL_CONNECTED call id 0x38, bchan 21, dsl 0

01:39:19: EVENT_FROM_ISDN: dchan_idb=0x63B3D334, call_id=0x38, ces=0x0

bchan=0x15, event=0x4, cause=0x0

01:39:19: EVENT_FROM_ISDN:(0038): DEV_CONNECTED at slot 1 and port 5

01:39:19: CSM_PROC_IC6_WAIT_FOR_CONNECT: CSM_EVENT_ISDN_CONNECTED at slot 1, port 5

01:39:19: CSM DSPLIB(1/5): np_dsplib_call_accept

01:39:19: ISDN Se7/6:23: EVENT to CSM:DEV_CONNECTED: calltype=VOICE, bchan=21

01:39:19: CSM DSPLIB(1/5):DSPLIB_MODEM_WAIT_ACTIVE: Modem session transition to ACTIVE

01:39:19: CSM DSPLIB(1/5): Modem state changed to (CONNECT_STATE)

01:39:22: CSM DSPLIB(1/5): Modem state changed to (V8BIS_EXCHANGE_STATE)

01:39:24: CSM DSPLIB(1/5): Modem state changed to (LINK_STATE)

01:39:28: CSM DSPLIB(1/5): Modem state changed to (RANGING_STATE)

01:39:30: CSM DSPLIB(1/5): Modem state changed to (HALF_DUPLEX_TRAIN_STATE)

01:39:45: CSM DSPLIB(1/5): Modem state changed to (TRAINUP_STATE)

01:39:45: CSM DSPLIB(1/5): Modem state changed to (EC_NEGOTIATING_STATE)

01:39:46: CSM DSPLIB(1/5): Modem state changed to (STEADY_STATE)

01:39:46: TTY1/05: DSR came up

01:39:46: tty1/05: Modem: IDLE->(unknown)

01:39:46: TTY1/05: EXEC creation

01:39:46: CHAT1/05: Attempting line activation script

01:39:46: CHAT1/05: Asserting DTR

01:39:50: voice_parse_intf_name: Using the old NAS_PORT string

01:39:50: voice_parse_intf_name: Using the old NAS_PORT string

01:39:50: AAA/AUTHEN/LOGIN (00000007): Pick method list 'default'

01:39:50: RADIUS/ENCODE(00000007): ask "Username: "

01:39:50: RADIUS/ENCODE(00000007): send packet; GET_USER

01:39:50: TTY1/05: set timer type 10, 30 seconds

01:39:50: TTY1/05: Autoselect(2) sample 7E

01:39:50: TTY1/05: Autoselect(2) sample 7EFF

01:39:50: TTY1/05: Autoselect(2) sample 7EFF7D

01:39:50: TTY1/05: Autoselect(2) sample 7EFF7D23

01:39:50: TTY1/05 Autoselect cmd: ppp negotiate

01:39:50: TTY1/05: EXEC creation

01:39:50: CHAT1/05: Attempting line activation script

01:39:50: CHAT1/05: Asserting DTR

01:39:54: voice_parse_intf_name: Using the old NAS_PORT string

01:39:54: voice_parse_intf_name: Using the old NAS_PORT string

01:39:54: TTY1/05: no timer type 1 to destroy

01:39:54: TTY1/05: no timer type 0 to destroy

01:39:54: As1/05 LCP: I CONFREQ [Closed] id 0 len 50

01:39:54: As1/05 LCP: ACCM 0x00000000 (0x020600000000)

01:39:54: As1/05 LCP: MagicNumber 0x00002EB8 (0x050600002EB8)

01:39:54: As1/05 LCP: PFC (0x0702)

01:39:54: As1/05 LCP: ACFC (0x0802)

01:39:54: As1/05 LCP: Callback 6 (0x0D0306)

01:39:54: As1/05 LCP: MRRU 1614 (0x1104064E)

01:39:54: As1/05 LCP: EndpointDisc 1 Local

01:39:54: As1/05 LCP: (0x131701CC7F60A0E7A211D6B549000102)

01:39:54: As1/05 LCP: (0x2BC43900000000)

01:39:54: As1/05 LCP: Lower layer not up, Fast Starting

01:39:54: voice_parse_intf_name: Using the old NAS_PORT string

01:39:54: voice_parse_intf_name: Using the old NAS_PORT string

01:39:54: As1/05 PPP: Treating connection as a callin

01:39:54: As1/05 PPP: Phase is ESTABLISHING, Passive Open

01:39:54: As1/05 LCP: State is Listen

01:39:54: As1/05 PPP: Authorization required

01:39:54: As1/05 LCP: O CONFREQ [Listen] id 1 len 25

01:39:54: As1/05 LCP: ACCM 0x000A0000 (0x0206000A0000)

01:39:54: As1/05 LCP: AuthProto CHAP (0x0305C22305)

01:39:54: As1/05 LCP: MagicNumber 0x099EBCBA (0x0506099EBCBA)

01:39:54: As1/05 LCP: PFC (0x0702)

01:39:54: As1/05 LCP: ACFC (0x0802)

01:39:54: As1/05 LCP: O CONFREJ [Listen] id 0 len 11

01:39:54: As1/05 LCP: Callback 6 (0x0D0306)

01:39:54: As1/05 LCP: MRRU 1614 (0x1104064E)

01:39:54: As1/05 LCP: I CONFACK [REQsent] id 1 len 25

01:39:54: As1/05 LCP: ACCM 0x000A0000 (0x0206000A0000)

01:39:54: As1/05 LCP: AuthProto CHAP (0x0305C22305)

01:39:54: As1/05 LCP: MagicNumber 0x099EBCBA (0x0506099EBCBA)

01:39:54: As1/05 LCP: PFC (0x0702)

01:39:54: As1/05 LCP: ACFC (0x0802)

01:39:54: As1/05 LCP: I CONFREQ [ACKrcvd] id 1 len 43

01:39:54: As1/05 LCP: ACCM 0x00000000 (0x020600000000)

01:39:54: As1/05 LCP: MagicNumber 0x00002EB8 (0x050600002EB8)

01:39:54: As1/05 LCP: PFC (0x0702)

01:39:54: As1/05 LCP: ACFC (0x0802)

01:39:54: As1/05 LCP: EndpointDisc 1 Local

01:39:54: As1/05 LCP: (0x131701CC7F60A0E7A211D6B549000102)

01:39:54: As1/05 LCP: (0x2BC43900000000)

01:39:54: As1/05 LCP: O CONFACK [ACKrcvd] id 1 len 43

01:39:54: As1/05 LCP: ACCM 0x00000000 (0x020600000000)

01:39:54: As1/05 LCP: MagicNumber 0x00002EB8 (0x050600002EB8)

01:39:54: As1/05 LCP: PFC (0x0702)

01:39:54: As1/05 LCP: ACFC (0x0802)

01:39:54: As1/05 LCP: EndpointDisc 1 Local

01:39:54: As1/05 LCP: (0x131701CC7F60A0E7A211D6B549000102)

01:39:54: As1/05 LCP: (0x2BC43900000000)

01:39:54: As1/05 LCP: State is Open

01:39:54: As1/05 PPP: Phase is AUTHENTICATING, by this end

01:39:54: As1/05 CHAP: O CHALLENGE id 1 len 26 from "s5400"

01:39:54: As1/05 LCP: I IDENTIFY [Open] id 2 len 18 magic 0x00002EB8 MSRASV4.00

01:39:54: As1/05 LCP: I IDENTIFY [Open] id 3 len 23 magic 0x00002EB8 MSRAS-1-PTE-PC1

01:39:54: As1/05 CHAP: I RESPONSE id 1 len 34 from "Administrator"

01:39:54: As1/05 PPP: Phase is FORWARDING, Attempting Forward

01:39:54: As1/05 PPP: Phase is AUTHENTICATING, Unauthenticated User

01:39:54: AAA/AUTHEN/PPP (00000007): Pick method list 'default'

01:39:54: As1/05 PPP: Sent CHAP LOGIN Request

01:39:54: RADIUS/ENCODE(00000007): Unsupported AAA attribute parent-interface

01:39:54: RADIUS/ENCODE(00000007): Unsupported AAA attribute parent-interface-type

01:39:54: RADIUS/ENCODE(00000007): acct_session_id: 9

01:39:54: RADIUS(00000007): sending

01:39:54: RADIUS: Send to unknown id 2 10.107.164.120:1645, Access-Request, len 128

01:39:54: RADIUS: authenticator 13 E4 F2 9F BC 3E CE 52 - CC 93 0C E0 01 0C 73 7B

01:39:54: RADIUS: Framed-Protocol [7] 6 PPP [1]

01:39:54: RADIUS: User-Name [1] 15 "Administrator"

01:39:54: RADIUS: CHAP-Password [3] 19 *

01:39:54: RADIUS: Called-Station-Id [30] 7 "50138"

01:39:54: RADIUS: Calling-Station-Id [31] 7 "60112"

01:39:54: RADIUS: Vendor, Cisco [26] 30

01:39:54: RADIUS: cisco-nas-port [2] 24 "Async1/05*Serial7/6:21"

01:39:54: RADIUS: NAS-Port [5] 6 221

01:39:54: RADIUS: NAS-Port-Type [61] 6 Async [0]

01:39:54: RADIUS: Service-Type [6] 6 Framed [2]

01:39:54: RADIUS: NAS-IP-Address [4] 6 10.0.58.107

01:39:54: RADIUS: Received from id 2 10.107.164.120:1645, Access-Accept, len 62

01:39:54: RADIUS: authenticator EF 45 A3 D4 A7 EE D0 65 - 03 50 B4 3E 07 87 2E 2F

01:39:54: RADIUS: Vendor, Cisco [26] 30

01:39:54: RADIUS: cisco-nas-port [2] 24 "Async1/05*Serial7/6:21"

01:39:54: RADIUS: Service-Type [6] 6 Framed [2]

01:39:54: RADIUS: Framed-Protocol [7] 6 PPP [1]

01:39:54: RADIUS: Received from id 7

01:39:54: As1/05 PPP: Received LOGIN Response PASS

01:39:54: As1/05 PPP/AAA: Check Attr: interface

01:39:54: As1/05 PPP/AAA: Check Attr: service-type

01:39:54: As1/05 PPP/AAA: Check Attr: Framed-Protocol

01:39:54: As1/05 PPP: Phase is FORWARDING, Attempting Forward

01:39:54: As1/05 PPP: Phase is AUTHENTICATING, Authenticated User

01:39:54: As1/05 AAA/AUTHOR/LCP: Process Author

01:39:54: As1/05 AAA/AUTHOR/LCP: Process Attr: service-type

01:39:54: As1/05 CHAP: O SUCCESS id 1 len 4

01:39:54: AAA/ACCT/NET(00000007): Pick method list 'default'

01:39:54: AAA/ACCT/SETMLIST(00000007): Handle FFFFFFFF, mlist 630B11E4, Name default

01:39:54: AAA/ACCT/EVENT/(00000007): NET UP

01:39:54: AAA/ACCT/NET(00000007): Queueing record is START

01:39:54: As1/05 PPP: Phase is UP

01:39:54: As1/05 AAA/AUTHOR/IPCP: FSM authorization not needed

01:39:54: As1/05 AAA/AUTHOR/FSM: We can start IPCP

01:39:54: As1/05 IPCP: O CONFREQ [Closed] id 1 len 10

01:39:54: As1/05 IPCP: Address 10.1.1.2 (0x030646010102)

01:39:54: AAA/ACCT(00000007): Accouting method=radius (radius)

01:39:54: RADIUS/ENCODE(00000007): Unsupported AAA attribute timezone

01:39:54: RADIUS/ENCODE(00000007): Unsupported AAA attribute parent-interface

01:39:54: RADIUS/ENCODE(00000007): Unsupported AAA attribute parent-interface-type

01:39:54: RADIUS(00000007): sending

01:39:54: RADIUS: Send to unknown id 8 10.107.164.120:1646, Accounting-Request, len 243

01:39:54: RADIUS: authenticator 41 87 FA 03 EB F9 94 62 - B2 3A 24 B8 27 4C A4 BC

01:39:54: RADIUS: Acct-Session-Id [44] 10 "00000009"

01:39:54: RADIUS: Framed-Protocol [7] 6 PPP [1]

01:39:54: RADIUS: Connect-Info [77] 26 "52000/28800 V90/V44/LAPM"

01:39:54: RADIUS: Vendor, Cisco [26] 48

01:39:54: RADIUS: Cisco AVpair [1] 42 "v92-info=V.92 QC MOH/No QC Requested/0/0"

01:39:54: RADIUS: Vendor, Cisco [26] 32

01:39:54: RADIUS: Cisco AVpair [1] 26 "connect-progress=Call Up"

01:39:54: RADIUS: Authentic [45] 6 RADIUS [1]

01:39:54: RADIUS: User-Name [1] 15 "Administrator"

01:39:54: RADIUS: Acct-Status-Type [40] 6 Start [1]

01:39:54: RADIUS: Called-Station-Id [30] 7 "50138"

01:39:54: RADIUS: Calling-Station-Id [31] 7 "60112"

01:39:54: RADIUS: Vendor, Cisco [26] 30

01:39:54: RADIUS: cisco-nas-port [2] 24 "Async1/05*Serial7/6:21"

01:39:54: RADIUS: NAS-Port [5] 6 221

01:39:54: RADIUS: NAS-Port-Type [61] 6 Async [0]

01:39:54: RADIUS: Service-Type [6] 6 Framed [2]

01:39:54: RADIUS: NAS-IP-Address [4] 6 10.0.58.107

01:39:54: RADIUS: Acct-Delay-Time [41] 6 0

01:39:54: RADIUS: Received from id 8 10.107.164.120:1646, Accounting-response, len 20

01:39:54: RADIUS: authenticator E5 5C D3 69 88 D5 2E 8E - 49 AF 63 22 01 53 33 7B

01:39:54: AAA/ACCT/NET(00000007): START protocol reply PASS

01:39:54: As1/05 CCP: I CONFREQ [Not negotiated] id 4 len 211

01:39:54: As1/05 CCP: Type254

01:39:54: As1/05 CCP: (0xFEC90100000000000000000000000000)

01:39:54: As1/05 CCP: (0x000074FFC7000000000068000000A000)

01:39:54: As1/05 CCP: (0x00006C20563905000000C0000000A400)

01:39:54: As1/05 CCP: (0x0000BC000000186400007000E80018C8)

01:39:54: As1/05 CCP: (0x130017CCF1770000000001000000E8FE)

01:39:54: As1/05 CCP: (0xC70076CDF17706000000000000000000)

01:39:54: As1/05 CCP: (0x00000000000000000000000000000000)

01:39:54: As1/05 CCP: (0x00000000000000000000000000000000)

01:39:54: As1/05 CCP: (0x00000000000000000000000000000000)

01:39:54: As1/05 CCP: (0x00000000000000000000220020000001)

01:39:54: As1/05 CCP: (0x0800000000005016B1CBA2E7D611B549)

01:39:54: As1/05 CCP: (0x0001022BC439C800000000000000C800)

01:39:54: As1/05 CCP: (0x00004D000000281FB8)

01:39:54: As1/05 CCP: MS-PPC supported bits 0x00000006 (0x120600000006)

01:39:54: As1/05 LCP: O PROTREJ [Open] id 2 len 217 protocol CCP

01:39:54: As1/05 LCP: (0x80FD010400D3FEC90100000000000000)

01:39:54: As1/05 LCP: (0x000000000000000074FFC70000000000)

01:39:54: As1/05 LCP: (0x68000000A00000006C20563905000000)

01:39:54: As1/05 LCP: (0xC0000000A4000000BC00000018640000)

01:39:54: As1/05 LCP: (0x7000E80018C8130017CCF17700000000)

01:39:54: As1/05 LCP: (0x01000000E8FEC70076CDF17706000000)

01:39:54: As1/05 LCP: (0x00000000000000000000000000000000)

01:39:54: As1/05 LCP: (0x00000000000000000000000000000000)

01:39:54: As1/05 LCP: (0x00000000000000000000000000000000)

01:39:54: As1/05 LCP: (0x00000000000000000000000000000000)

01:39:54: As1/05 LCP: (0x2200200000010800000000005016B1CB)

01:39:54: As1/05 LCP: (0xA2E7D611B5490001022BC439C8000000)

01:39:54: As1/05 LCP: (0x00000000C80000004D000000281FB812)

01:39:54: As1/05 LCP: (0x0600000006)

01:39:54: As1/05 IPCP: I CONFREQ [REQsent] id 5 len 34

01:39:54: As1/05 IPCP: Address 0.0.0.0 (0x030600000000)

01:39:54: As1/05 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)

01:39:54: As1/05 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)

01:39:54: As1/05 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)

01:39:54: As1/05 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)

01:39:54: As1/05 AAA/AUTHOR/IPCP: Start. Her address 0.0.0.0, we want 10.2.2.6

01:39:54: As1/05 AAA/AUTHOR/IPCP: Authorization succeeded

01:39:54: As1/05 AAA/AUTHOR/IPCP: Done. Her address 0.0.0.0, we want 10.2.2.6

01:39:54: As1/05 AAA/AUTHOR/IPCP: no author-info for primary dns

01:39:54: As1/05 AAA/AUTHOR/IPCP: no author-info for primary wins

01:39:54: As1/05 AAA/AUTHOR/IPCP: no author-info for seconday dns

01:39:54: As1/05 AAA/AUTHOR/IPCP: no author-info for seconday wins

01:39:54: As1/05 IPCP: O CONFREJ [REQsent] id 5 len 28

01:39:54: As1/05 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)

01:39:54: As1/05 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)

01:39:54: As1/05 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)

01:39:54: As1/05 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)

01:39:54: As1/05 IPCP: I CONFACK [REQsent] id 1 len 10

01:39:54: As1/05 IPCP: Address 70.1.1.2 (0x030646010102)

01:39:54: As1/05 IPCP: I CONFREQ [ACKrcvd] id 6 len 10

01:39:54: As1/05 IPCP: Address 0.0.0.0 (0x030600000000)

01:39:54: As1/05 IPCP: O CONFNAK [ACKrcvd] id 6 len 10

01:39:54: As1/05 IPCP: Address 70.2.2.6 (0x030646020206)

01:39:55: As1/05 IPCP: I CONFREQ [ACKrcvd] id 7 len 10

01:39:55: As1/05 IPCP: Address 70.2.2.6 (0x030646020206)

01:39:55: As1/05 IPCP: O CONFACK [ACKrcvd] id 7 len 10

01:39:55: As1/05 IPCP: Address 70.2.2.6 (0x030646020206)

01:39:55: As1/05 IPCP: State is Open

01:39:55: AAA/ACCT/EVENT/(00000007): IPCP_PASS

01:39:55: As1/05 IPCP: Install route to 10.2.2.6

01:39:55: As1/05 IPCP: Add link info for cef entry 10.2.2.6

Debug Output 2

01:40:50: ISDN Se7/6:23: RX <- DISCONNECT pd = 8 callref = 0x42A0

01:40:50: Cause i = 0x8190 - Normal call clearing

01:40:50: ISDN Se7/6:23: LIF_EVENT: ces/callid 1/0x38 CALL_DISC

01:40:50: EVENT_FROM_ISDN: dchan_idb=0x63B3D334, call_id=0x38, ces=0x0

bchan=0x15, event=0x0, cause=0x10

01:40:50: EVENT_FROM_ISDN:(0038): DEV_IDLE at slot 1 and port 5

01:40:50: CSM_PROC_IC7_OC6_CONNECTED: CSM_EVENT_ISDN_DISCONNECTED at slot 1, port 5

01:40:50: CSM DSPLIB(1/5): np_dsplib_call_hangup reason 14

01:40:50: CSM(1/5): Enter csm_enter_disconnecting_state

01:40:50: VDEV_DEALLOCATE: slot 1 and port 5 is deallocated

01:40:50: ISDN Se7/6:23: EVENT to CSM:DEV_IDLE: calltype=VOICE, bchan=21

01:40:50: ISDN Se7/6:23: process_disc_ack(): call id 0x38, ces 0, call type VOICE cause 0x10

01:40:50: ISDN Se7/6:23: TX -> RELEASE pd = 8 callref = 0xC2A0

01:40:50: AAA/ACCT/EVENT/(00000007): CALL STOP

01:40:50: AAA/ACCT/CALL STOP(00000007): Sending stop requests

01:40:50: AAA/ACCT(00000007): Send all stops

01:40:50: AAA/ACCT/NET(00000007): STOP

01:40:50: AAA/ACCT/NET(00000007): Queueing record is STOP osr 1

01:40:50: AAA/ACCT(00000007): Accouting method=radius (radius)

01:40:50: RADIUS/ENCODE(00000007): Unsupported AAA attribute timezone

01:40:50: RADIUS/ENCODE(00000007): Unsupported AAA attribute parent-interface

01:40:50: RADIUS/ENCODE(00000007): Unsupported AAA attribute parent-interface-type

01:40:50: RADIUS(00000007): sending

01:40:50: RADIUS: Send to unknown id 9 10.107.164.120:1646, Accounting-Request, len 315

01:40:50: RADIUS: authenticator 2E 6A 04 D0 04 9A D3 D5 - F7 DD 99 E0 C3 99 27 60

01:40:50: RADIUS: Acct-Session-Id [44] 10 "00000009"

01:40:50: RADIUS: Framed-Protocol [7] 6 PPP [1]

01:40:50: RADIUS: Framed-IP-Address [8] 6 70.2.2.6

01:40:50: RADIUS: Acct-Terminate-Cause[49] 6 lost-carrier [2]

01:40:50: RADIUS: Vendor, Cisco [26] 33

01:40:50: RADIUS: Cisco AVpair [1] 27 "disc-cause-ext=No Carrier"

01:40:50: RADIUS: Vendor, Cisco [26] 35

01:40:50: RADIUS: Cisco AVpair [1] 29 "connect-progress=LAN Ses Up"

01:40:50: RADIUS: Acct-Session-Time [46] 6 56

01:40:50: RADIUS: Connect-Info [77] 26 "52000/28800 V90/V44/LAPM"

01:40:50: RADIUS: Vendor, Cisco [26] 48

01:40:50: RADIUS: Cisco AVpair [1] 42 "v92-info=V.92 QC MOH/No QC Requested/0/0"

01:40:50: RADIUS: Acct-Input-Octets [42] 6 285

01:40:50: RADIUS: Acct-Output-Octets [43] 6 295

01:40:50: RADIUS: Acct-Input-Packets [47] 6 5

01:40:50: RADIUS: Acct-Output-Packets [48] 6 5

01:40:50: RADIUS: User-Name [1] 15 "Administrator"

01:40:50: RADIUS: Acct-Status-Type [40] 6 Stop [2]

01:40:50: RADIUS: Called-Station-Id [30] 7 "50138"

01:40:50: RADIUS: Calling-Station-Id [31] 7 "60112"

01:40:50: RADIUS: Vendor, Cisco [26] 30

01:40:50: RADIUS: cisco-nas-port [2] 24 "Async1/05*Serial7/6:21"

01:40:50: RADIUS: NAS-Port [5] 6 221

01:40:50: RADIUS: NAS-Port-Type [61] 6 Async [0]

01:40:50: RADIUS: Service-Type [6] 6 Framed [2]

01:40:50: RADIUS: NAS-IP-Address [4] 6 10.0.58.107

01:40:50: RADIUS: Acct-Delay-Time [41] 6 0

01:40:50: RADIUS: Received from id 9 10.107.164.120:1646, Accounting-response, len 20

01:40:50: RADIUS: authenticator D0 3F 32 D7 7C 8C 5E 22 - 9A 69 EF 17 AC 32 81 21

01:40:50: AAA/ACCT/NET(00000007): STOP protocol reply PASS

01:40:50: AAA/ACCT/NET(00000007): Cleaning up from Callback osr 0

01:40:50: AAA/ACCT(00000007): del node, session 9

01:40:50: AAA/ACCT/NET(00000007): free_rec, count 0

01:40:50: AAA/ACCT/NET(00000007) reccnt 0, csr TRUE, osr 0

01:40:50: AAA/ACCT/NET(00000007): Last rec in db, intf not enqueued

01:40:50: ISDN Se7/6:23: RX <- RELEASE_COMP pd = 8 callref = 0x42A0

01:40:50: ISDN Se7/6:23: CCPRI_ReleaseCall(): bchan 22, call id 0x38, call type VOICE

01:40:50: CCPRI_ReleaseChan released b_dsl 0 B_Chan 22

01:40:50: ISDN Se7/6:23: LIF_EVENT: ces/callid 1/0x38 CALL_CLEARED

01:40:50: ISDN Se7/6:23: received CALL_CLEARED call_id 0x38

01:40:50: no resend setup, no redial

01:40:50: no resend setup, no redial

01:40:50: AAA/ACCT/DS0: channel=21, ds1=6, t3=0, slot=7, ds0=117465109

01:40:50: EVENT_FROM_ISDN: dchan_idb=0x63B3D334, call_id=0x38, ces=0x1

bchan=0x15, event=0x0, cause=0x0

01:40:50: ISDN Se7/6:23: EVENT to CSM:DEV_IDLE: calltype=VOICE, bchan=21

01:40:51: CSM DSPLIB(1/5): Modem state changed to (TERMINATING_STATE)

01:40:51: CSM DSPLIB(1/5): Modem went onhook

01:40:51: CSM_PROC_IC8_OC8_DISCONNECTING: CSM_EVENT_MODEM_ONHOOK at slot 1, port 5

01:40:51: CSM(1/5): Enter csm_enter_idle_state

01:40:51: CSM DSPLIB(1/5):DSPLIB_IDLE: Modem session transition to FLUSHING

01:40:51: CSM DSPLIB(1/5):DSPLIB_IDLE: Modem session transition to IDLE

01:40:51: TTY1/05: DSR was dropped

01:40:51: tty1/05: Modem: READY->(unknown)

01:40:52: TTY1/05: dropping DTR, hanging up

01:40:52: DSPLIB(1/5): np_dsplib_process_dtr_notify()

01:40:52: CSM DSPLIB(1/5): Modem went onhook

01:40:52: CSM_PROC_IDLE: CSM_EVENT_MODEM_ONHOOK at slot 1, port 5

01:40:52: TTY1/05: Async Int reset: Dropping DTR

01:40:52: tty1/05: Modem: HANGUP->(unknown)

01:40:52: AAA/ACCT/EVENT/(00000007): NET DOWN

01:40:52: As1/05 IPCP: Remove link info for cef entry 70.2.2.6

01:40:52: As1/05 IPCP: State is Closed

01:40:52: As1/05 PPP: Phase is TERMINATING

01:40:52: As1/05 LCP: State is Closed

01:40:52: As1/05 PPP: Phase is DOWN

01:40:52: As1/05 IPCP: Remove route to 70.2.2.6

01:40:52: As1/05 LCP: State is Closed

01:40:53: TTY1/05: cleanup pending. Delaying DTR

01:40:54: TTY1/05: cleanup pending. Delaying DTR

01:40:55: TTY1/05: cleanup pending. Delaying DTR

01:40:56: TTY1/05: cleanup pending. Delaying DTR

01:40:57: TTY1/05: no timer type 0 to destroy

01:40:57: TTY1/05: no timer type 1 to destroy

01:40:57: TTY1/05: no timer type 3 to destroy

01:40:57: TTY1/05: no timer type 4 to destroy

01:40:57: TTY1/05: no timer type 2 to destroy

01:40:57: Async1/05: allowing modem_process to continue hangup

01:40:57: TTY1/05: restoring DTR

01:40:57: TTY1/05: autoconfigure probe started

01:40:57: As1/05 LCP: State is Closed

Verifying V.92 Call Information

commands:

SUMMARY

- show modem [ slot / port | group number ]

- show port modem log [ reverse slot / port ] [ slot | slot / port ]

- show users [ all ]

DETAILED STEPS

Command or Action

Purpose

Step 1

Router# show modem 1/0 group 1

Displays a high-level performance report for all the modems or a single modem inside Cisco access servers.

Step 2

]

Router# show port modem log

Displays the events generated by the modem sessions.

Step 3

Router# show users

Displays information about the active lines on the router.

Examples

commands:

Show Output 1

Router# show port modem log 1/05

Port 1/05 Events Log

01:46:19: Service Type: DATA_FAX_MODEM

01:46:19: Service Mode: DATA_FAX_MODEM

01:46:19: Session State: IDLE

01:46:19: incoming caller number: 60112

01:46:19: incoming called number: 50138

01:46:19: Service Type: DATA_FAX_MODEM

01:46:19: Service Mode: DATA_FAX_MODEM

01:46:19: Session State: IDLE

01:46:19: Service Type: DATA_FAX_MODEM

01:46:19: Service Mode: DATA_FAX_MODEM

01:46:19: Session State: ACTIVE

01:46:19: Modem State event:

State: Connect

01:46:20: Modem State event:

State: V.8bis Exchange

01:46:20: Modem State event:

State: Link

01:46:20: Modem State event:

State: Ranging

01:46:20: Modem State event:

State: Half Duplex Train

01:46:20: Modem State event:

State: Train Up

01:46:20: Modem State event:

State: EC Negotiating

01:46:20: Modem State event:

State: Steady

01:46:20: Modem Static event:

Connect Protocol : LAP-M

Compression : V.44

Connected Standard : V.90

TX,RX Symbol Rate : 8000, 3200

TX,RX Carrier Frequency : 0, 1829

TX,RX Trellis Coding : 16/No trellis

Frequency Offset : 0 Hz

Round Trip Delay : 0 msecs

TX,RX Bit Rate : 52000, 28800

Robbed Bit Signalling (RBS) pattern : 255

Digital Pad : 6 dB

Digital Pad Compensation : Enabled

MNP10EC : Off-None

QC Exchange : No QC Requested

TX,RX Negotiated String Length : 255, 255

DC TX,RX Negotiated Codewords : 1024, 1024

DC TX,RX Negotiated History Size : 4096, 5120

01:46:21: ISDN Se7/6:23: RX <- SERVICE pd = 3 callref = 0x0000

01:46:21: Change Status i = 0xC0 - in-service

01:46:21: Channel ID i = 0xA98381

01:46:21: ISDN Se7/6:23: Incoming call id = 0x003A, dsl 0

01:46:21: ISDN Se7/6:23: LIF_EVENT: ces/callid 1/0x0 CHAN_STATUS

01:46:21: ISDN Se7/6:23: CHAN_STATUS B-chan=1, action=2; Maintenance.

01:46:21: ISDN Se7/6:23: TX -> SERVICE ACKNOWLEDGE pd = 3 callref = 0x8000

01:46:21: Change Status i = 0xC0 - in-service

01:46:21: Channel ID i = 1

s5400#sh port modem log 1/05

Port 1/05 Events Log

01:46:30: Service Type: DATA_FAX_MODEM

01:46:30: Service Mode: DATA_FAX_MODEM

01:46:30: Session State: IDLE

01:46:30: incoming caller number: 60112

01:46:30: incoming called number: 50138

01:46:30: Service Type: DATA_FAX_MODEM

01:46:30: Service Mode: DATA_FAX_MODEM

01:46:30: Session State: IDLE

01:46:30: Service Type: DATA_FAX_MODEM

01:46:30: Service Mode: DATA_FAX_MODEM

01:46:30: Session State: ACTIVE

01:46:30: Modem State event:

State: Connect

01:46:30: Modem State event:

State: V.8bis Exchange

01:46:30: Modem State event:

State: Link

01:46:30: Modem State event:

State: Ranging

01:46:30: Modem State event:

State: Half Duplex Train

01:46:30: Modem State event:

State: Train Up

01:46:31: Modem State event:

State: EC Negotiating

01:46:31: Modem State event:

State: Steady

01:46:31: Modem Static event:

Connect Protocol : LAP-M

Compression : V.44

Connected Standard : V.90

TX,RX Symbol Rate : 8000, 3200

TX,RX Carrier Frequency : 0, 1829

TX,RX Trellis Coding : 16/No trellis

Frequency Offset : 0 Hz

Round Trip Delay : 0 msecs

TX,RX Bit Rate : 52000, 28800

Robbed Bit Signalling (RBS) pattern : 255

Digital Pad : 6 dB

Digital Pad Compensation : Enabled

MNP10EC : Off-None

QC Exchange : No QC Requested

TX,RX Negotiated String Length : 255, 255

DC TX,RX Negotiated Codewords : 1024, 1024

DC TX,RX Negotiated History Size : 4096, 5120

Diagnostic Code : 00 00 00 00 00 00 00 00

V.92 Status : V.92 QC MOH

01:46:32: Modem Dynamic event:

Sq Value : 6

Signal Noise Ratio : 38 dB

Receive Level : -11 dBm

Phase Jitter Frequency : 0 Hz

Phase Jitter Level : 0 degrees

Far End Echo Level : 0 dBm

Phase Roll : 0 degrees

Total Retrains : 0

EC Retransmission Count : 0

Characters transmitted, received : 0, 0

Characters received BAD : 0

PPP/SLIP packets transmitted, received : 0, 0

PPP/SLIP packets received (BAD/ABORTED) : 0

EC packets transmitted, received OK : 0, 0

EC packets (Received BAD/ABORTED) : 0

Total Speedshifts : 0

Total MOH Time : 0 secs

Current MOH Time : 0 secs

MOH Status : Modem is Not on Hold

MOH Count : 0

MOH Request Count : 0

Retrains due to Call Waiting : 0

DC Encoder,Decoder State : compressed/compressed

DC TX,RX Compression Ratio : not calculated/not calculated

DC TX,RX Dictionary Reset Count : 0, 0

Diagnostic Code : 00 00 00 00 00 00 00 00

01:46:35: Modem State event:

State: Terminate

01:46:35: Service Type: DATA_FAX_MODEM

01:46:35: Service Mode: DATA_FAX_MODEM

01:46:35: Session State: FLUSHING

01:46:35: Service Type: DATA_FAX_MODEM

01:46:35: Service Mode: DATA_FAX_MODEM

01:46:35: Session State: IDLE

01:46:35: Modem End Connect event:

Call Timer : 65 secs

Disconnect Reason Info : 0x220

Type (=0 ): <unknown>

Class (=2 ): EC condition - locally detected

Reason (=32 ): received DISC frame -- normal LAPM termination

Total Retrains : 0

EC Retransmission Count : 0

Characters transmitted, received : 677, 817

Characters received BAD : 0

PPP/SLIP packets transmitted, received : 10, 10

PPP/SLIP packets received (BAD/ABORTED) : 0

EC packets transmitted, received OK : 10, 21

EC packets (Received BAD/ABORTED) : 0

TX,RX Bit Rate : 52000, 28800

Total Speedshifts : 0

Total MOH Time : 0 secs

Current MOH Time : 0 secs

MOH Status : Modem is Not on Hold

MOH Count : 0

MOH Request Count : 0

Retrains due to Call Waiting : 0

DC Encoder,Decoder State : compressed/compressed

DC TX,RX Compression Ratio : 1.67:1/1.65:1

DC TX,RX Dictionary Reset Count : 0, 1

Diagnostic Code : 00 00 00 00 00 00 00 00

01:46:37:Modem Link Rate event:

Show Output 2

Router# show users

Line User Host(s) Idle Location

* 0 con 0 idle 00:00:00

tty 1/05 Administra Async interface 00:00:29 PPP: 70.2.2.6

Interface User Mode Idle Peer Address

Troubleshooting Tips

command.

Additional References

For additional information related to the V.92 Reporting Using RADIUS Attribute v.92-info feature, refer to the following references:

Related Documents

Related Topic

Document Title

AAA accounting

AAA accounting commands

, Release 12.3.

V.92 Quick Connect feature

V.92 Modem on Hold feature

Standards

Standards

Title

No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.

—

MIBs

MIBs

MIBs Link

No new or modified MIBs are supported by this feature, and support for existing MIBs has not been modified by this feature.

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

RFCs

RFCs

Title

No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.

Technical Assistance

Description

Link

Technical Assistance Center (TAC) home page, containing 30,000 pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.

Command Reference

.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2001-2008 Cisco Systems, Inc. All rights reserved.

Configuring and Managing Cisco Access Servers and Dial Shelves

This chapter describes configuration and monitoring tasks for the Cisco AS5800 and AS5400 access servers, including dial shelves and dial shelf controllers on the Cisco AS5800 access servers in the following main sections:

- Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental © 2007–2009 Cisco Systems, Inc. All rights reserved.Cisco AS5800 Dial Shelf Architecture and DSIP Overview

- How to Configure Dial Shelves

- Port Management Services on Cisco Access Servers

- Upgrading and Configuring SPE Firmware

Software Configuration Guide.

Operations, Administration, Maintenance, and Provisioning Guide.

For more information on the Cisco access servers, go to the Cisco Connection Documentation site on Cisco.com, or use the Cisco Documentation CD-ROM.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

Cisco AS5800 Dial Shelf Architecture and DSIP Overview

The Cisco AS5800 is a rack-mounted system consisting of a router shelf and a dial shelf. The dial shelf contains feature and controller cards (trunk cards), modem cards, and dial shelf controller (DSC) cards.

Note For more information about split dial shelf configuration, refer to the hardware installation guides that accompanied your Cisco AS5800 Universal Access Server and the Cisco AS5800 Universal Access Server Software Installation and Configuration Guide.

The Dial Shelf Interconnect Protocol (DSIP) is used for communication between router shelf and dial shelf on an AS5800. Figure 1 diagrams the components of the architecture. The router shelf is the host for DSIP commands, which can be run remotely on the feature boards of the dial shelf using the command, execute-on. DSIP communicates over the packet backplane via the dial shelf interconnect (DSI) cable.

Figure 1 DSIP Architecture in the Cisco AS5800

Split Dial Shelves Feature

The split dial shelves feature provides for doubling the throughput of the Cisco AS5800 access server by splitting the dial shelf slots between two router shelves, each router connected to one Dial Shelf Controller (DSC), two of which must be installed in the system. Each router shelf is configured to control a certain set from the range of the dial shelf slots. Each router shelf will operate as though any other slots in the dial shelf contained no cards, even if there is a card in them, because they are controlled by the other router shelf. Thus the configuration on each router shelf would affect only the “owned” slots.

Each router shelf should own modem cards and trunk cards. Calls received on a trunk card belonging to one router shelf cannot be serviced by a modem card belonging to the other router shelf. Each router shelf operates like a single Cisco AS5800 access server system, as if some slots are unavailable.

Refer to the section “Configuring Dial Shelf Split Mode” for more information about configuring split dial shelves.

How to Configure Dial Shelves

To configure and maintain dial shelves, perform the tasks in the following sections:

- Configuring the Shelf ID

- Configuring Redundant DSC Cards

- Synchronizing to the System Clocks

- Configuring Dial Shelf Split Mode

- Executing Commands Remotely

- Verifying DSC Configuration

- Monitoring and Maintaining the DSCs

- Troubleshooting DSIP

Configuring the Shelf ID

The Cisco AS5800 consists of a router shelf and a dial shelf. To distinguish the slot/port number on the Cisco AS5800, you must specify the shelf number. The default shelf number is 0 for the router shelf and 1 for the dial shelf.

Caution You must reload the Cisco AS5800 for the new shelf number to take effect. Because the shelf number is part of the interface names when you reload, all NVRAM interface configuration information is lost.

.

command.

commands in global configuration mode, as indicated in the following steps:

Command

Purpose

Step 1

Saves your current configuration. Changing the shelf number removes all interface configuration information when you reload the Cisco AS5800.

Step 2

Begins global configuration mode.

Step 3

Specifies the router shelf ID.

Step 4

Specifies the dial shelf ID.

Step 5

Exits global configuration mode.

Step 6

Saves your configuration. This step is optional.

Step 7

Verifies that the correct shelf number will be changed after the next reload.

Step 8

Router# reload components all

Instructs the DSC (or DSCs in a redundant configuration) be reloaded at the same time as a reload on the router shelf.

Type “yes” to the “save config” prompt.

Configure one interface so that its router shelf has connectivity to the server with the configuration.

Step 9

Because changing the shelf number removes all interface configuration information when you reload the Cisco AS5800, edit the configuration file saved in step 1 and download it.

If you are booting the router shelf from Flash memory, use the following commands beginning in EXEC mode:

Command

Purpose

Step 1

or

Saves your current (latest) configuration to a server.

Step 2

Begins global configuration mode.

Step 3

Configures the router shelf ID.

Step 4

Configures the dial shelf ID.

Step 5

Exits global configuration mode.

Step 6

Saves your configuration. This step is optional. If this step is skipped, type “No” at the “save configuration” prompt.

Step 7

Allows verification that the correct shelf number will be changed after the next reload.

Edit the configuration file saved in Step 1.

Step 8

Copies the edited configuration to NVRAM on the Cisco AS5800.

Step 9

Router# reload components all

Instructs the DSC (or DSCs in a redundant configuration) to be reloaded at the same time as a reload on the router shelf.

Configuring Redundant DSC Cards

The Redundant Dial Shelf Controller feature consists of two DSC cards on a Cisco AS5800 dial shelf. The DSC cards provide clock and power control to the dial shelf cards. Each DSC card provides the following:

- Master clock for the dial shelf

- Fast Ethernet link to the router shelf

- Environmental monitoring of the feature boards

- Bootstrap images on start-up for the feature boards

The Redundant Dial Shelf Controller feature is automatically enabled when two DSC cards are installed. DSC redundancy is supported with Cisco AS5800 software at the Dial Shelf Interconnect Protocol (DSIP) level.

This feature enables a Cisco AS5800 dial shelf to use dual DSCs for full redundancy. A redundant configuration allows for one DSC to act as backup to the active card, should the active card fail. This increases system availability by preventing loss of service. The redundant DSC functionality is robust under high loads and through DSC or software crashes and reloads. The redundant DSC functionality is driven by the following events:

- User actions

- Control messages

- Timeouts

- Detection of component failures

- Error and warning messages

DSC redundancy provides maximum system availability by preventing loss of service if one of the DSCs fails. There is no load sharing between the Broadband Inter-Carrier Interfaces (BICI). One BIC is used as a backup, carrying only control traffic, such as keepalives, until there is a switchover.

Before starting this configuration task:

- Your Cisco AS5800 router shelf and dial shelf must be fully installed, with two DSC cards installed on the dial shelf.

- Your Cisco AS5800 access server must be running Cisco IOS Release 12.1(2)T.

- The external DSC clocking port must be configured identically on both router shelves and must be physically connected to both DSCs. This assures that if a DSC card needs replacing or if the backup DSC card becomes primary, clocking remains stable.

Synchronizing to the System Clocks

The time-division multiplexing (TDM) bus in the backplane on the dial shelf must be synchronized to the T1/E1 clocks on the trunk cards. The Dial Shelf Controller (DSC) card on the daily shelf provides hardware logic to accept multiple clock sources as input and use one of them as the primary source to generate a stable, PPL synchronized output clock. The input clock can be any of the following sources:

- Trunk port in slots 0 through 5—up to 12 can be selected (2 per slot)

- An external T1 or E1 clock source fed directly through a connector on the DSC card

- A free-running clock from an oscillator in the clocking hardware on the DSC card

For dual (redundant) DSC cards, the external DSC clocking port should be configured so that the clock signal fed into both DSCs is identical.

To configure the external clocks, use the following commands from the router shelf login beginning in global configuration mode. One external clock is configured as the primary clock source, and the other is configured as the backup clock source.

Command

Purpose

Step 1

Router(config )# dial-tdm-clock priority value

Configures the trunk card clock priority. Priority range is a value between 1 and 50.

Step 2

Router(config )# dial-tdm-clock priority X { trunk-slot Y port Z } external { t1 | e1 } [ 120-ohm ]

Selects the T1/E1 trunk slot and port that is providing the clocking source. T1/E1 selection is based on the incoming signal. Select the impedance. The default impedance is 75-ohm.

Step 3

Router(config )# dial-tdm-clock priority value external t1

or

Router(config )# dial-tdm-clock priority value external e1

Configures the T1/E1 external clock on the dial shelf controller front panel. T1/E1 selection is based on the signal coming in. Priority range is a value between 1 and 50.

Step 4

Router(config)# Ctrl-Z

Router#

to return to privileged EXEC mode.

Step 5

Router# copy running-config startup-config

Saves your changes.

Verifying External Clock Configuration

To verify that the primary clock is running, enter the show dial-shelf clocks privileged EXEC command:

Router# show dial-shelf 12 clocks

Slot 12:

System primary is 1/2/0 of priority 202

TDM Bus Master Clock Generator State = NORMAL

Backup clocks:

Source Slot Port Priority Status State

-------------------------------------------------------

Trunk 2 1 208 Good Default

Slot Type 11 10 9 8 7 6 5 4 3 2 1 0

2 T1 G G G G G G G G G G G G

Configuring Dial Shelf Split Mode

This section describes the procedure required to transition a router from normal mode to split mode and to change the set of slots a router owns while it is in split mode. Since the process of switching the ownership of a slot from one router to the other is potentially disruptive (when a feature board is restarted, all calls through that card are lost), a router shelf cannot take over a slot until ownership is relinquished by the router that currently claims ownership, either by reconfiguring the router or disconnecting that router or its associated DSC.

The dial shelf is split by dividing the ownership of the feature boards between the two router shelves. You must configure the division of the dial shelf slots between the two router shelves so that each router controls an appropriate mix of trunk and modem cards. Each router shelf controls its set of feature boards as if those were the only boards present. There is no interaction between feature boards owned by one router and feature boards owned by the other router.

command, the router frees any resources associated with cards in the slots that it no longer owns, as specified by exclusion of slot numbers from the slot-numbers argument. The router should be in the same state as if the card had been removed from the slot; all calls through that card will be terminated. The configured router then informs its connected DSC that it is in split mode, and which slots it claims to own.

command is entered when the total number of calls using timeslots exceeds the number that would normally be available to the router in split mode, the command is rejected. This should occur only when a change to split mode is attempted, in which the dial shelf has more than 896 calls in progress (more than half of the 1,792 available timeslots). Otherwise, a transition from normal mode to split mode can be made without disturbing the cards in the slots that remain owned, and calls going through those cards will stay up.

To configure a router for split dial shelf operation, perform the following steps:

Step 1 Ensure that both DSCs and both router shelves are running the same Cisco IOS image.

Note Having the same version of Cisco IOS running on both DSCs and both router shelves is not mandatory; however, it is a good idea. There is no automatic checking that the versions are the same.

Step 2 Schedule a time when the Cisco AS5800 can be taken out of service without unnecessarily terminating calls in progress. The entire procedure for transitioning from normal mode to split mode should require approximately one hour if all the hardware is already installed.

Step 3 Busy out all feature boards and wait for your customers to log off.

Step 4 Reconfigure the existing router shelf to operate in split mode.

command, specifying the slot numbers that are to be owned by the existing router shelf.

Step 6 Configure the new router shelf to operate in split mode on other feature boards.

command, specifying the slot numbers that are to be owned by the new router shelf. Do not specify any of the slot numbers that you specified in Step 6. The range of valid slot numbers is 0 through 11.

To perform this step, enter the following command in global configuration mode:

Command

Purpose

Router(config)# dial-shelf split slots slot-numbers

Enter list of slot numbers, for example:

dial-shelf split slots 0 1 2 6 7 8

In this example, the other router shelf could be configured to own the other slots: 3 4 5 9 10 11.

: This command changes the router shelf to split mode with ownership of the slots listed.

command to the other router shelf to display its list of owned dial shelf slots.

Online insertion and removal (OIR) events on all slots are detected by both DSCs and added to the list of feature boards physically present in the dial shelf; however, OIR event processing is done only for assigned slots.

: This command adds the dial shelf slots listed to the router shelf’s list of owned dial shelf slots.

Step 8 Install the second DSC, if it has not already been installed.

Step 9 Connect the DSIP cable from the second DSC to the new router shelf.

Step 10 Ensure that split mode is operating properly.

Enter the show dial-shelf command for each router. This command has been extended so that the response indicates that the router shelf is running in split mode and which slots the router shelf owns. The status of any cards in any owned slots is shown, just as they are in the present show dial-shelf command. When in split mode, the output will be extended as in the following example:

System is in split dial shelf mode.

Slots owned: 0 2 3 4 5 6 (connected to DSC in slot 13)

Slot Board CPU DRAM I/O Memory State Elapsed

Type Util Total (free) Total (free) Time

0 CE1 0%/0% 21341728( 87%) 8388608( 45%) Up 00:11:37

2 CE1 0%/0% 21341728( 87%) 8388608( 45%) Up 00:11:37

4 Modem(HMM) 20%/20% 6661664( 47%) 6291456( 33%) Up 00:11:37

5 Modem(DMM) 0%/0% 6661664( 31%) 6291456( 32%) Up 00:11:37

6 Modem(DMM) 0%/0% 6661664( 31%) 6291456( 32%) Up 00:11:37

13 DSC 0%/0% 20451808( 91%) 8388608( 66%) Up 00:16:31

Dial shelf set for auto boot

Step 11 Enable all feature boards to accept calls once again.

Changing Slot Sets

You can change the sets of slots owned by the two router shelves while they are in split mode by first removing slots from the set owned by one router, and then adding them to the slot set of the other router. The changed slot set information is sent to the respective DSCs, and the DSCs determine which slots have been removed and which added from the new slot set information. It should be clear that moving a slot in this manner will disconnect all calls that were going through the card in that slot.

To perform this task, enter the following commands as needed:

Command

Purpose

Router (config)# dial-shelf split slots remove slot-numbers

Removes the dial shelf slots listed from the router shelf’s list of owned dial shelf slots. The effect of multiple commands is cumulative.

Router(config)# dial-shelf split slots slot-numbers

Adds the dial shelf slots listed to the router shelf’s list of owned dial shelf slots.

When a Slot Is Removed

The router shelf that is losing the slot frees any resources and clears any state associated with the card in the slot it is relinquishing. The DSC reconfigures its hub to ignore traffic from that slot, and if there is a card in the slot, it will be reset. This ensures that the card frees up any TDM resource it might be using and allows it to restart under control of the router shelf that is subsequently configured to own the slot.

When a Slot Is Added

If there are no configuration conflicts, and there is a card present in the added slot, a dial-shelf OIR insertion event is sent to the router shelf, which processes the event the same as it always does. The card in the added slot is reset by the DSC to ensure a clean state, and the card downloads its image from the router shelf that now owns it.

command surrendering the ownership claim on the slot by one of the routers.

Leaving Split Mode

command. When the split dial shelf line is removed, the router shelf will start using all of the TDM timeslots. Feature boards that were not owned in split mode and that are not owned by the other router will be reset. Cards in slots that are owned by the other router will be reset, but only after the other DSC has been removed or is no longer claiming the slots. The split dial shelf configuration should not be removed while the second router shelf is still connected to the dial shelf.

When a router configured in split mode fails, all calls associated with the failed router are lost. Users cannot connect back in until the failed router recovers and is available to accept new incoming calls; however, the other split mode router shelf will continue to operate normally.

Troubleshooting Split Dial Shelves

The system will behave as configured as soon as the configuration is changed. The exception is when there is a misconfiguration, such as when one router is configured in split mode and the other router is configured in normal mode, or when both routers are configured in split mode and both claim ownership of the same slots.

command is entered and the command would result in a conflict, the command is rejected.

If a conflict in slot ownership does arise, both routers will receive warning messages until the conflict is resolved. Any card in a slot which is claimed by both routers remains under the control of the router that claimed it first, until you can resolve the conflict by correcting the configuration of one or both routers.

It should be noted that there can also be slots that are not owned by either router (orphan slots). Cards in orphan slots cannot boot up until one of the two routers claims ownership of the slot because neither DSC will download bootstrap images to cards in unowned orphan slots.

Managing a Split Dial Shelf

If you are installing split dial shelf systems, a system controller is available that provides a single system view of multiple point of presences (POPs). The system controller for the Cisco AS5800 Universal Access Server includes the Cisco 3640 router running Cisco IOS software. The system controller can be installed at a remote facility so that you can access multiple systems through a console port or Web interface.

There are no new MIBs or MIB variables required for the split dial shelf configuration. A split dial shelf appears to Simple Network Management Protocol (SNMP) management applications as two separate Cisco AS5800 systems. One console to manage the whole system is not supported—you must have a console session per router shelf (two console sessions) to configure each split of the Cisco AS5800. The system controller must manage a split dial shelf configuration as two separate Cisco AS5800 systems.

The normal mode configuration of the Cisco AS5800 requires the dial shelf and router shelf IDs to be different. In a split system, four unique shelf IDs are desirable, one for each router shelf and one for each of the slot sets; however, a split system will function satisfactorily if the router shelf IDs are the same. If a system controller is used to manage a split dial shelf configuration, the two routers must have distinct shelf IDs, just as they must when each router has its own dial shelf.

You can download software configurations to any Cisco AS5800 using SNMP or a Telnet connection. The system controller also provides performance monitoring and accounting data collection and logging.

In addition to the system controller, a network management system with a graphical user interface (GUI) runs on a UNIX SPARC station and includes a database management system, polling engine, trap management, and map integration.

To manage a split dial shelf, enter the following commands in EXEC mode as needed:

Command

Purpose

Router# show dial-shelf split

Displays the slots assigned to each of the router shelves and the corresponding feature boards in ‘orphan’ slots (slots not currently assigned to either router).

Router# show dial-shelf

Displays information about the dial shelf, including clocking information.

Router# show context

to display all the information available about any slot. This is intended to cover the case where ownership of a feature board is moved from one router shelf to the other after a crash.

Executing Commands Remotely

.

To enter a command that you wish to execute on a specific card installed in the dial shelf while logged onto the router shelf console, use the following commands in privileged EXEC mode as needed:

Command

Purpose

Executes a command from the router shelf on a specific slot in the dial shelf.

Executes a command from the router shelf on all cards in the dial shelf.

Verifying DSC Configuration

privileged EXEC command:

Router# show redundancy

DSC in slot 12:

Hub is in 'active' state.

Clock is in 'active' state.

DSC in slot 13:

Hub is in 'backup' state.

Clock is in 'backup' state.

Router#

Monitoring and Maintaining the DSCs

To monitor and maintain the DSC cards, use the following commands in privileged EXEC mode, as needed:

Command

Purpose

Router# hw-module shelf / slot { start | stop }

Stops the target DSC remotely from the router console. Restart the DSC if it has been stopped.

Router# show redundancy [ history ]

Displays the current or history status for redundant DSC.

Router# debug redundancy { all | ui | clk | hub }

Use this debug command if you need to collect events for troubleshooting, selecting the appropriate required key word.

Router# show debugging

Lists the debug commands that are turned on, including those for redundant DSC.

Troubleshooting DSIP

There are a number of show commands available to aid in troubleshooting dial shelves. Use the following EXEC mode commands to monitor DSI and DSIP activity as needed:

Command

Purpose

Clears tracing statistics for the DSIP.

Displays all information about the DSIP.

Displays information about DSIP clients.

Displays information about the processors running the DSIP.

Displays information about local and remote ports.

Displays the number of messages in the retransmit queue waiting for acknowledgment.

Displays DSIP tracing buffer information.

Displays information about the DSIP transport statistics for the control/data and IPC packets and registered addresses.

Displays DSIP version information.

command can also be used to troubleshoot, as it displays the status of the DSI adapter, which is used to physically connect the router shelf and the dial shelf to enable DSIP communications.

The following is an example troubleshooting scenario:

The router shelf boots, but there is no communication between the router and dial shelves.

command.

Step 2 Check the “DSIP registered addresses” column. If there are zero entries there, there is some problem with the Dial Shelf Interconnect (DSI). Check if the DSI is installed in the router shelf.

Step 3 If there is only one entry and it is our own local address, then first sanity check the physical layer. Make sure that there is a physical connection between the RS and DS. If everything is fine from cabling point of view, go to step 3.

command. This gives a consolidated output of DSI controller and interface. Check for any errors like runts, giants, throttles and other usual FE interface errors.

If an entry for a particular dial shelf slot is not found among the registered addresses, but most of other card entries are present, the problem is most likely with that dial shelf slot. The DSI hardware on that feature board is probably bad.

Port Management Services on Cisco Access Servers

Port Management Services on the Cisco AS5400 Access Server

Port service management on the Cisco AS5400 access server implements service using the NextPort dial feature card (DFC). The NextPort DFC is a hardware card that processes digital service port technology for the Cisco AS5400 access server. A port is defined as an endpoint on a DFC card through which multiservice tones and data flow. The ports on the NextPort DFC support both modem and digital services. Ports can be addressed-aggregated at the slot level of the NextPort module, the Service Processing Element (SPE) level within the NextPort module, and the individual port level. Cisco IOS Release 12.1(3)T or higher is required for the NextPort DFC.

.

The NextPort DFC slot is defined as a value between 1 and 7. Slot 0 is reserved for the motherboard. Each NextPort DFC provides 18 SPEs. The SPE value ranges from 0 to 17. Since each SPE has six ports, the NextPort DFC has a total of 108 ports. The port value ranges from 0 to 107.

The NextPort DFC performs the following functions:

- Converts pulse code modulation (PCM) bitstreams to digital packet data.

- Forwards converted and packetized data to the main processor, which examines the data and forwards it to the backhaul egress interface.

- Supports all modem standards (such as V.34 and V.42bis) and features, including dial-in and dial-out.

Port Management Services on the Cisco AS5800 Access Server

Port service management on the Cisco AS5800 access server implements service on the Universal Port Card (UPC). A universal port carries a single channel at the speed of digital signal level 0 (DS0), or the equivalent of 64-kbps on a T1 facility.

Network traffic can be a modem, voice, or fax connection. The 324 port UPC uses NextPort hardware and firmware to provide universal ports for the Cisco AS5800 access server. These ports are grouped into 54 service processing elements (SPEs). Each SPE supports six universal ports. To find the total number of ports supported by a UPC, multiply the 54 SPEs by the six ports supported on each SPE. The total number of universal ports supported by a single UPC is 324. Configuration, management, and troubleshooting of universal ports can be done at the UPC, SPE, and port level. Each UPC also has a SDRAM card with a minimum of a 128 MB of memory.

The Cisco AS5800 access server can be equipped with a maximum of seven UPCs with upgradable firmware. The UPC supports data traffic, and depending on the software and platform is universal port capable. Each UPC plugs directly into the dial shelf backplane and does not need any external connections. Each UPC has three LEDs, which indicate card status.

The Cisco AS5800 access server is capable of terminating up to 2,048 incoming modem connections (slightly more than an OC3) when equipped with seven UPCs and three CT3 trunk cards. A split shelf configuration with a second router shelf and second dial shelf controller are required to achieve full capacity. A single router with a standard configuration supports up to 1,344 port connections. Cisco IOS Release 12.1(3)T or higher is required for the UPC. Unless your system shipped with UPCs installed, you must upgrade the Cisco IOS image on the dial shelf and router shelf or shelves.

.

A UPC can be installed in slots numbered 2 to 11 on the dial shelf backplane. If installed in slots 0 or 1, the UPC automatically powers down. Slots 0 and 1 only accept trunk cards; they do not accept mixes of cards. We recommend that you install mixes of T3 and T1 cards, or E1 trunk cards in slots 2 to 5. You can use double-density modem cards, UPCs, and VoIP cards simultaneously. Trunk cards can operate in slots 0 to 5 and are required for call termination.

The UPC performs the following functions:

- Converts pulse code modulation (PCM) bitstreams to digital packet data.

- Forwards converted and packetized data to the dial shelf main processor, which examines the data and forwards it to the router shelf. From the router shelf, the data is routed to the external network.

- Supports all modem standards (such as V.34 and V.42bis) and features, including dial-in and dial-out.

- Supports online insertion and removal (OIR), a feature that allows you to remove and replace UPCs while the system is operating. A UPC can be removed without disrupting the operation of other cards and their associated calls. If a UPC is removed while the system is operating, connections or current calls on that card are dropped. Calls being handled by other cards are not affected.

Note All six ports on an SPE run the same firmware.

Upgrading and Configuring SPE Firmware

SPE firmware is automatically downloaded in both the Cisco AS5400 and AS5800 access servers.

AS5400 Access Server

SPE firmware is automatically downloaded to a NextPort DFC from the Cisco AS5400 when you boot the system for the first time, or when you insert a NextPort DFC while the system is operating. When you insert DFCs while the system is operating, the Cisco IOS image recognizes the cards and downloads the required firmware to the cards.

The SPE firmware image is bundled with the access server Cisco IOS image. The SPE firmware image uses an autodetect mechanism, which enables the NextPort DFC to service multiple call types. An SPE detects the call type and automatically configures itself for that operation. For further information on upgrading SPE firmware from the Cisco IOS image, refer to the section “Configuring SPEs to Use an Upgraded Firmware File.”

The firmware is upgradeable independent of Cisco IOS upgrades, and different firmware versions can be configured to run on SPEs in the same NextPort DFC. You can download firmware from the Cisco System Cisco.com File Transfer Protocol (FTP) server.

AS5800 Access Server

SPE firmware is automatically downloaded to an AS5800 UPC from the router shelf Cisco IOS image when you boot the system for the first time or when you insert a UPC while the system is operating. The Cisco IOS image recognizes the card and the dial shelf downloads the required portware to the cards. Cisco IOS Release 12.1(3)T or higher is required for the UPC.

The SPE firmware image (also known as portware) is bundled with the Cisco IOS UPC image. The SPE firmware image uses an autodetect mechanism, which enables the UPC to service multiple call types. An SPE detects the call type and automatically configures itself for that operation. For further information on upgrading SPE firmware from the Cisco IOS image, refer to the section “Configuring SPEs to Use an Upgraded Firmware File.”

The firmware is upgradable independent of Cisco IOS upgrades, and different firmware versions can be configured to run on SPEs in the same UPC. You can download firmware from the Cisco.com File Transfer Protocol (FTP) server.

Firmware Upgrade Task List

Upgrading SPE firmware from the Cisco.com FTP server is done in two steps:

- Downloading SPE Firmware from the Cisco.com FTP Server to a Local TFTP Server

- Copying the SPE Firmware File from the Local TFTP Server to the SPEs

Firmware Configuration Task List

To complete firmware configuration once you have downloaded the SPE firmware, perform the tasks in the following sections:

- Specifying a Country Name

- Configuring Dial Split Shelves (AS5800 Only)

- Configuring SPEs to Use an Upgraded Firmware File

- Disabling SPEs

- Rebooting SPEs

- Configuring Lines

- Configuring Ports

- Verifying SPE Line and Port Configuration

- Configuring SPE Performance Statistics

- Clearing Log Events

- Troubleshooting SPEs

- Monitoring SPE Performance Statistics

Note The following procedure can be used for either a Cisco AS5400 or AS5800 access server.

Downloading SPE Firmware from the Cisco.com FTP Server to a Local TFTP Server

Note You must be a registered Cisco user to log in to the Cisco Software Center.

You can download software from the Cisco Systems Cisco.com FTP server using an Internet browser or using an FTP application. Both procedures are described.

Using an Internet Browser

Step 1 Launch an Internet browser.

Step 2 Bring up the Cisco Software Center home page at the following URL (this is subject to change without notice):

http://www.cisco.com/kobayashi/sw-center/

(under Cisco Software Products) to open the Access Software window.

software.

.

Step 6 Click the SPE firmware file you want to download, and then follow the remaining download instructions. If you are downloading the SPE firmware file to a PC, make sure that you download the file to the c:/tftpboot directory; otherwise, the download process does not work.

Step 7 When the SPE firmware is downloaded to your workstation, transfer the file to a Trivial File Transfer Protocol (TFTP) server in your LAN using a terminal emulation software application.

Step 8 When the SPE firmware is downloaded to your workstation, transfer the file to a TFTP server somewhere in your LAN using a terminal emulation software application.

Using an FTP Application

Note The directory path leading to the SPE firmware files on cco.cisco.com is subject to change without notice. If you cannot access the files using an FTP application, try the Cisco Systems URL http://www.cisco.com/cgi-bin/ibld/all.pl?i=support&c=3.

Step 1 Log in to the Cisco.com FTP server called cco.cisco.com:

terminal> ftp cco.cisco.com

Connected to cio-sys.cisco.com.

):

Name (cco.cisco.com:harry): harry

331 Password required for harry.

Password: letmein

230-#############################################################

230-# Welcome to the Cisco Systems CCO FTP server.

230-# This server has a number of restrictions. If you are not familiar

230-# with these, please first get and read the /README or /README.TXT file.

230-# http://www.cisco.com/acs/info/cioesd.html for more info.

230-#############################################################

Step 3 Specify the directory path that holds the SPE firmware you want to download. For example, the directory path for the Cisco AS5400 SPE firmware is /cisco/access/5400:

ftp> cd /cisco/access/5400

250-Please read the file README

250- it was last modified on Tue May 27 10:07:38 1997 - 48 days ago

250-Please read the file README.txt

250- it was last modified on Tue May 27 10:07:38 1997 - 48 days ago

250 CWD command successful.

command to view the contents of the directory:

ftp> ls

227 Entering Passive Mode (192,31,7,130,218,128)

150 Opening ASCII mode data connection for /bin/ls.

total 2688

drwxr-s--T 2 ftpadmin ftpcio 512 Jun 30 18:11 .

drwxr-sr-t 19 ftpadmin ftpcio 512 Jun 23 10:26 ..

lrwxrwxrwx 1 root 3 10 Aug 6 1996 README ->README.txt

-rw-rw-r-- 1 root ftpcio 2304 May 27 10:07 README.txt

-r--r--r-- 1 ftpadmin ftpint 377112 Jul 10 18:08 np-spe-upw-10.0.1.2.bin

-r--r--r-- 1 ftpadmin ftpint 635 Jul 10 18:08 SPE-firmware.10.1.30.readme

Step 5 Specify a binary image transfer:

ftp> binary

200 Type set to I.

command.

Step 7 Quit your terminal session:

ftp> quit

Goodbye.

command to verify that you successfully transferred the files to your local directory:

server% ls -al

total 596

-r--r--r-- 1 280208 Jul 10 18:08 np-spe-upw-10.0.1.2.bin

server% pwd

/auto/tftpboot

Step 9 Transfer these files to a local TFTP or remote copy protocol (RCP) server that your access server or router can access.

Copying the SPE Firmware File from the Local TFTP Server to the SPEs

The procedure for copying the SPE firmware file from your local TFTP server to the Cisco AS5400 NextPort DFCs or Cisco AS5800 UPCs is a two-step process. First, transfer the SPE firmware to the access server’s Flash memory. Then, configure the SPEs to use the upgrade firmware. The upgrade occurs automatically, either as you leave configuration mode, or as specified in the configuration.

These two steps are performed only once. After you copy the SPE firmware file into Flash memory for the first time, you should not have to perform these steps again.

Note Because the SPE firmware is configurable for individual SPEs or ranges of SPEs, the Cisco IOS software automatically copies the SPE firmware to each SPE each time the access server restarts.

To transfer SPE Firmware to Flash memory, perform the following task to download the Universal SPE firmware to Flash memory:

Step 1 Check the image in the access server Flash memory:

Router# show flash

System flash directory:

File Length Name/status

1 4530624 c5400-js-mx

[498776 bytes used, 16278440 available, 16777216 total]

16384K bytes of processor board System flash (Read/Write)

Step 2 Enter the copy tftp flash command to download the code file from the TFTP server into the access server Flash memory. You are prompted for the download destination and the remote host name.

Router# copy tftp flash

command to verify that the file has been copied into the access server Flash memory:

Router# show flash

Specifying a Country Name

To set the Cisco AS5400 NextPort DFCs or Cisco AS5800 UPCs to be operational for call set up, you must specify the country name. To specify the country name, use the following command in global configuration mode:

Command

Purpose

form of this command to set the country code to the default of the domestic country.

Note All sessions in all UPCs or DFCs in all slots must be in the idle state for this command to execute.

Configuring Dial Split Shelves (AS5800 Only)

The Cisco AS5800 access server requires a split dial shelf configuration using two router shelves to achieve the maximum capacity of 2048 port connections using the seven UPCs and three T3 + 1 T1 trunks. A new configuration command is available to define the split point:

The options for this command come in pairs, and vary according to the desired configuration. You will need to log in to each router shelf and separately configure the routers for the intended load. In most circumstances it is recommended that the predefined options are selected. These options are designed to be matched pairs as seen below.

Option Pair

Router Shelf 1

Router Shelf 2

Total

Option

Maximum Calls

Unused T1

Option

Maximum Calls

Unused T1

1

2ct3cas

1344

1ct3cas

672

2016

2

part2ct1ct3cas

1152

4

part1ct1ct3cas

888

3

2040

3

2ct3isdn

1288

part1ct1ct3isdn_b

644

7

1932

4

part2ct1ct3isdn

1150

2

part1ct1ct3isdn

897

1

2047

5 1

3ce1

960

3ce1

960

1920

6

Default (no option entered)

1/2 of current input

Default (no option entered)

1/2 of current input

7

no dial-shelf backplane-ds0

1024

no dial-shelf backplane-ds0

1024

2048

1.This option is used to revert to the default for an environment using 6 E1 lines.

1.This option is used to revert to the default for an environment using 6 E1 lines.

option to define your own split.

Even if your system is already using a split dial shelf configuration, configuring one router shelf to handle two T3 trunks and the other router to handle the third trunk requires you to take the entire access server out of service. Busyout all connections before attempting to reconfigure. The configuration must be changed to setup one pool of TDM resources that can be used by either DMM cards or UPCs, and a second pool of two streams that contains TDM resources that can only be used by UPCs.

You may have more trunk capacity than 2048 calls. It is your decision how to provision the trunks so the backplane capacity is not exceeded. If more calls come in than backplane DS0 capacity for that half of the split, the call will be rejected and an error message printed for each call. This cannot be detected while a new configuration is being built because the router cannot tell which T1 trunks are provisioned and which are not. The user may want some trunks in hot standby.

command will show the resources in two groups, the first 1792 accessible to all cards, and the remaining 256 accessible only to UPC and trunk cards.

and the hardware installation guides that accompanied your Cisco AS5800 Universal Access Server.

Configuring SPEs to Use an Upgraded Firmware File

To configure the SPEs to use the upgraded firmware file, use the following commands beginning in privileged EXEC mode to display the firmware version number:

Command

Purpose

Step 1

Router# show spe version

Displays SPE firmware versions to obtain the On-Flash firmware filename.

Step 2

Enters global configuration mode.

Step 3

AS5400:

or

AS5800:

or

Enters the SPE configuration mode. You can choose to configure a range of SPEs by specifying the first and last SPE in the range.

Step 4

}

Specifies the upgrade method.

keyword requests the access server to upgrade firmware at the next reboot.

Step 5

Specifies the SPE firmware file in Flash memory to use for the selected SPEs. Allows you to upgrade firmware for SPEs after the new SPE firmware image is copied to your Flash memory.

command to revert back to the default Cisco IOS bundled SPE firmware.

Step 6

Exits SPE configuration mode.

Step 7

Exits global configuration mode.

Step 8

Saves your changes.

Note The copy ios-bundled command is not necessary with UPCs or NextPort DFCs. By default, the version of SPE firmware bundled with the Cisco IOS software release transfers to all SPEs not specifically configured for a different SPE firmware file.

Disabling SPEs

To disable specific SPEs in the Cisco AS5400 NextPort DFCs or Cisco AS5800 UPCs, use the following commands starting in global configuration mode:

Command

Purpose

Step 1

Cisco AS5400 Series Routers

or

Cisco AS5800 Series Routers

or

Enters SPE configuration mode. You can also configure SPEs specifying the first and last SPE in a range.

Step 2

Gracefully disables an SPE by waiting for all the active services on the specified SPE to terminate.

command to see the state of the range of SPEs.

form of this command to re-enable the SPEs.

Step 3

Clears active calls on all ports on the SPE. Calls can no longer be placed on the SPE because the SPE state is changed to Busiedout.

Use the no form of this command to re-enable the ports on the SPE.

Rebooting SPEs

To reboot specified SPEs, use the following command in privileged EXEC mode:

Command

Purpose

Cisco AS5400 Series Routers

Cisco AS5800 Series Routers

Allows manual recovery of a port that is frozen in a suspended state. Reboots SPEs that are in suspended or Bad state. Downloads configured firmware to the specified SPE or range of SPEs and power-on self test (POST) is executed.

Note Depending on the problem, sometimes downloading the SPE firmware may not help recover a bad port or an SPE.
This command can be executed regardless of the state of SPEs. All active ports running on the SPE are prematurely terminated, and messages are logged into the appropriate log.

Configuring Lines

To configure the lines to dial in to your network, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Cisco AS5400 Series Routers

Cisco AS5800 Series Routers

Enters the line configuration mode. You can specify a range of slot and port numbers to configure.

.

.

Step 2

Allows all protocols when connecting to the line.

Step 3

Enables remote IP users running a PPP application to dial in, bypass the EXEC facility, and connect directly to the network.

Step 4

Enables incoming and outgoing calls.

Step 5

Configures the attached modem using the entry for name.

Configuring Ports

This section describes how to configure Cisco AS5800 UPC or Cisco AS5400 NextPort DFC ports. You need to be in port configuration mode to configure these ports. The port configuration mode allows you to shut down or put individual ports or ranges of ports in busyout mode. To configure Cisco AS5800 UPC or Cisco AS5400 NextPort DFC ports, perform the following tasks beginning in global configuration mode:

Command

Purpose

Step 1

Cisco AS5400 Series Routers

or

Cisco AS5800 Series Routers

or

Enters port configuration mode. You can choose to configure a single port or range of ports.

Step 2

(Optional) Gracefully disables a port by waiting for the active services on the specified port to terminate. Use the no form of this command to re-enable the ports.

Maintenance activities, such as testing, can still be performed while the port is in busyout mode.

Note When a port is in busyout mode, the state of the SPE is changed to the consolidated states of all the underlying ports on that SPE.

Step 3

(Optional) Clears active calls on the port. No more calls can be placed on the port in the shutdown mode. Use the no form of this command to re-enable the ports.

Note When a port is in shutdown mode, the state of the SPE is changed to the consolidated states of all the underlying ports on that SPE.

Step 4

Exits port configuration mode.

Verifying SPE Line and Port Configuration

To verify your SPE line configuration, enter the show spe command to display a summary for all the lines and ports:

Step 1 Enter the show spe command to display a summary for all the lines and ports:

Router# show spe

Step 2 Enter the show line command to display a summary for a single line.

AS5400

Router# show line 1/1

AS5800

Router# show line 1/2/10

Note If you are having trouble, make sure that you have turned on the protocols for If you are having trouble, make sure that you have turned on the protocols for connecting to the lines (transport input all) and that your access server is configured for incoming and outgoing calls (modem inout).

Configuring SPE Performance Statistics

commands listed in the section “Monitoring SPE Performance Statistics.” You can configure some aspects of history events by using one of the following commands in global configuration mode:

Command

Purpose

form of this command.

Sets the maximum size of the history event queue log entry for each port. The default is 50 events per port.

Clearing Log Events

To clear some or all of the log events relating to the SPEs as needed, use the following privileged EXEC mode commands:

Command

Purpose

Clears all event entries in the slot history event log.

Clears statistical counters for all types of services for the specified SPE, a specified range of SPEs, or all SPEs. If you do not specify the range of SPEs or an SPE, the statistics for all SPEs are cleared.

Clears all event entries in the port level history event log. You cannot remove individual service events from the port log.

Troubleshooting SPEs

This section provides troubleshooting information for your SPEs regardless of service type mode.

Note SPE ports that pass the diagnostic test are marked as Pass, Fail, and Unkn. Ports that fail the diagnostic test are marked as Bad. These ports cannot be used for call connections. Depending on how many ports are installed, the diagnostic tests may take from 5 to 10 minutes to complete.

- Enter the port modem startup-test command to perform diagnostic testing for all modems during the system's initial startup or rebooting process. To disable the test, enter the no port modem startup-test command.

- Enter the port modem autotest command to perform diagnostic testing for all ports during the system’s initial startup or rebooting process.To disable the test, enter the no port modem autotest command.

You may additionally configure the following options:

efine the minimum number of free ports available for autotest to begin.

enable autotesting time and interval.

- Enter the show port modem test command to displays results of the SPE port startup test and SPE port auto-test.

When an SPE port is tested as Bad, you may perform additional testing by conducting a series of internal back-to-back connections and data transfers between two SPE ports. All port test connections occur inside the access server. For example, if mobile users cannot dial into port 2/5 (which is the sixth port on the NextPort DFC in the second chassis slot), attempt a back-to-back test with port 2/5 and a known-functioning port such as port 2/6.

- Enter the test port modem back-to-back slot / port slot / port command to perform internal back-to-back port tests between two ports sending test packets of the specified size.

Note You might need to enable this command on several different combinations of ports to determine which one is not functioning properly. A pair of operable ports successfully connects and completes transmitting data in both directions. An operable port and an inoperable port do not successfully connect with each other.

A sample back-to-back test might look like the following:

Router# test port modem back-to-back 2/10 3/20

Repetitions (of 10-byte packets) [1]:

*Mar 02 12:13:51.743:%PM_MODEM_MAINT-5-B2BCONNECT:Modems (2/10) and (3/20) connected in back-to-back test:CONNECT33600/V34/LAP

*Mar 02 12:13:52.783:%PM_MODEM_MAINT-5-B2BMODEMS:Modems (3/20) and (2/10) completed back-to-back test:success/packets = 2/2

Tip You may reboot the port that has problems using the clear spe EXEC command.

- Enter the spe recovery { port-action { disable | recover | none } | port-threshold num-failures } command to perform automatic recovery (removal from service and reloading of SPE firmware) of ports on an SPE at any available time.

is 30 consecutive call failures.

Tip You may also schedule recovery using the spe download maintenance command.

- Enter the spe download maintenance time hh : mm | stop-time hh : mm | max-spes number | window time-period | expired-window { drop-call | reschedule } command to perform a scheduled recovery of SPEs.

option. This process continues until the number of SPEs under maintenance is below max-spes, or until stop-time (if set), or until all SPEs marked for recovery or upgrade have had their firmware reloaded.

Monitoring SPE Performance Statistics

This section documents various SPE performance statistics for the Cisco AS5400 NextPort DFCs or Cisco AS5800 UPCs:

- SPE Events and Firmware Statistics

- Port Statistics

- Digital SPE Statistics

- SPE Modem Statistics

SPE Events and Firmware Statistics

To view SPE events and firmware statistics for the Cisco AS5400 NextPort DFCs or Cisco AS5800 UPCs, use one or more of the following commands in privileged EXEC mode:

Command

Purpose

Cisco AS5400 series routers

Cisco AS5800 series routers

Displays the SPE status for the specified range of SPEs.

]

Displays the SPE system log.

SPEs and the SPE firmware files used.

Note This list helps you decide if you need to update your SPE firmware files.

Port Statistics

To view port statistics for the Cisco AS5400 NextPort DFCs or Cisco AS5800 UPCs, use the following commands in privileged EXEC mode as needed:

Command

Purpose

Cisco AS5400 series routers

}

Cisco AS5800 series routers

}

Displays the configuration information for specified ports or the specified port range. The port should have an active session associated at the time the command is executed.

Cisco AS5400 series routers

]

Displays the digital data event log.

Cisco AS5400 series routers

]

Cisco AS5800 series routers

]

Displays the port history event log.

Cisco AS5400 series routers

]

Cisco AS5800 series routers

]

Displays the test log for the specified SPE port range or all the SPE ports.

Cisco AS5400 series routers

]

Cisco AS5800 series routers

]

Displays the operational status of the specified ports or the specified port range. The port should have an active session associated at the time the command is executed.

Digital SPE Statistics

To view digital SPE statistics for the Cisco AS5400 NextPort DFCs, use one or more of the following commands in privileged EXEC mode:

Command

Purpose

]

Displays history statistics of all digital SPEs.

]

Displays active digital statistics of a specified SPE, the specified range of SPEs, or all the SPEs.

]

Displays the digital call success rate statistics for a specific SPE, a range of SPEs, or all the SPEs.

]

Displays the digital disconnect reasons for the specified SPE or range of SPEs. The disconnect reasons are displayed with Class boundaries.

]

SPE Modem Statistics

To view SPE modem statistics for the Cisco AS5400 NextPort DFCs or Cisco AS5800 UPCs, use one or more of the following commands in privileged EXEC mode:

Command

Purpose

Cisco AS5400 series routers

spe}

Cisco AS5800 series router:

spe}

Displays the active statistics of a specified SPE, a specified range of SPEs, or all the SPEs serving modem traffic.

Cisco AS5400 series routers

}

Cisco AS5800 series routers

}

Displays the call success rate statistics for a specific SPE, range of SPEs, or all the SPEs.

Cisco AS5400 series routers

}

Cisco AS5800 series routers

}

Displays the disconnect reasons for the specified SPE or range of SPEs. The disconnect reasons are displayed with Class boundaries.

Cisco AS5400 series routers

}

Cisco AS5800 series routers

}

Shows the connect-speeds negotiated within each high speed modulation or codecs for a specific range of SPEs or all the SPEs.

Cisco AS5400 series routers

}

Cisco AS5800 series routers

}

Shows the connect-speeds negotiated within each low speed modulation or codecs for a specific range of SPEs or all the SPEs.

Cisco AS5400 series routers

}

Cisco AS5800 series routers

}

Displays the total number of connections within each low modulation or codec for a specific range of SPEs.

Cisco AS5400 series routers

}

Cisco AS5800 series routers

}

Displays the total number of connections within each high modulation or codec for a specific range of SPEs.

Cisco AS5400 series routers

}

Cisco AS5800 series routers

}

Displays the history statistics of all SPEs, specified SPE or the specified range of SPEs.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental

© 2007–2009 Cisco Systems, Inc. All rights reserved.

Configuring and Managing External Modems

This chapter describes how to configure externally connected modems. These tasks are presented in the following main sections:

- External Modems on Low-End Access Servers

- Automatically Configuring an External Modem

- Manually Configuring an External Modem

- Supporting Dial-In Modems

- Testing the Modem Connection

- Managing Telnet Sessions

- Modem Troubleshooting Tips

- Checking Other Modem Settings

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

External Modems on Low-End Access Servers

Some of the Cisco lower-end access servers, such as the Cisco AS2511-RJ shown in Figure 1, have cable connections to external modems. The asynchronous interfaces and lines are inside the access server.

Figure 1 Cisco AS2511-RJ Access Server

When you configure modems to function with your access server, you must provide initialization strings and other settings on the modem to tell it how to function with the access server.

This section assumes that you have already physically attached the modem to the access server. If not, refer to the user guide or installation and configuration guide for your access server for information about attaching modems.

Automatically Configuring an External Modem

The Cisco IOS software can issue initialization strings automatically, in a file called a modemcap, for most types of modems externally attached to the access server. A modemcap is a series of parameter settings that are sent to your modem to configure it to interact with the Cisco device in a specified way. The Cisco IOS software defines modemcaps that have been found to properly initialize most modems so that they function properly with Cisco routers and access servers. For Cisco IOS Release 12.2, these modemcaps have the following names:

- default—Generic Hayes interface external modem

- codex_3260—Motorola Codex 3260 external

- usr_courier—U.S. Robotics Courier external

- usr_sportster—U.S. Robotics Sportster external

- hayes_optima—Hayes Optima external 1

- global_village—Global Village Teleport external

- viva—Viva (Rockwell ACF with MNP) external

- telebit_t3000—Telebit T3000 external

- nec_v34—NEC V.34 external

- nec_v110—NEC V.110 TA external

- nec_piafs—NEC PIAFS TA external

1 The hayes_optima modemcap is not recommended for use; instead, use the default modemcap.

command.

command to configure it, as described in the procedure “Using the Modem Autoconfigure Discovery Feature.”

Using the Modem Autoconfigure Type Modemcap Feature

command to define your own modemcap entry.

The following example defines modemcap MODEMCAPNAME:

Router(config)# modemcap edit MODEMCAPNAME miscellaneous &FS0=1&D3

Step 2 Apply the modemcap to the modem lines as shown in the following example:

Router# terminal monitor

Router# debug confmodem

Modem Configuration Database debugging is on

Router# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)# line 33 34

Router(config-line)# modem autoconfigure type MODEMCAPNAME

Router(config-line)#

Jan 16 18:12:59.643: TTY34: detection speed (115200) response ---OK---

Jan 16 18:12:59.643: TTY34: Modem command: --AT&FS0=1&D3--

Jan 16 18:12:59.659: TTY33: detection speed (115200) response ---OK---

Jan 16 18:12:59.659: TTY33: Modem command: --AT&FS0=1&D3--

Jan 16 18:13:00.227: TTY34: Modem configuration succeeded

Jan 16 18:13:00.227: TTY34: Detected modem speed 115200

Jan 16 18:13:00.227: TTY34: Done with modem configuration

Jan 16 18:13:00.259: TTY33: Modem configuration succeeded

Jan 16 18:13:00.259: TTY33: Detected modem speed 115200

Jan 16 18:13:00.259: TTY33: Done with modem configuration

Using the Modem Autoconfigure Discovery Feature

command.

The following example shows how to configure modem autoconfigure discovery mode:

Router# terminal monitor

Router# debug confmodem

Modem Configuration Database debugging is on

Router# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)# line 33 34

Router(config-line)# modem autoconfigure discovery

Jan 16 18:16:17.724: TTY33: detection speed (115200) response ---OK---

Jan 16 18:16:17.724: TTY33: Modem type is default

Jan 16 18:16:17.724: TTY33: Modem command: --AT&F&C1&D2S0=1H0--

Jan 16 18:16:17.728: TTY34: detection speed (115200) response ---OK---

Jan 16 18:16:17.728: TTY34: Modem type is default

Jan 16 18:16:17.728: TTY34: Modem command: --AT&F&C1&D2S0=1H0--

Jan 16 18:16:18.324: TTY33: Modem configuration succeeded

Jan 16 18:16:18.324: TTY33: Detected modem speed 115200

Jan 16 18:16:18.324: TTY33: Done with modem configuration

Jan 16 18:16:18.324: TTY34: Modem configuration succeeded

Jan 16 18:16:18.324: TTY34: Detected modem speed 115200

Jan 16 18:16:18.324: TTY34: Done with modem configuration

Manually Configuring an External Modem

If you cannot configure your modem automatically, you must configure it manually. This section describes how to determine and issue the correct initialization string for your modem and how to configure your modem with it.

command sets.

to view, inspect, or observe the settings.

Timesaver You must first create a direct Telnet or connection session to the modem before you can send an initialization string. You can use AT&F as a basic modem initialization string in most cases. To establish a direct Telnet session to an external modem, determine the IP address of your LAN (Ethernet) interface, and then enter a Telnet command to port 2000 + n on the access server, where n is the line number to which the modem is connected. See the sections “Testing the Modem Connection” and “Managing Telnet Sessions” for more information about making Telnet connections.

A sample modem initialization string for a US Robotics Courier modem is as follows:

&b1&h1&r2&c1&d3&m4&k1s0=1

Modem initialization strings enable the following functions:

- Locks the speed of the modem to the speed of the serial port on the access server

- Sets hardware flow control (RTS/CTS or request to send/clear to send)

- Ensures correct data carrier detect (DCD) operation

- Ensures proper data terminal ready (DTR) interpretation

- Answers calls on the first ring

Note Make sure to turn off automatic baud rate detection because the modem speeds must be set to a fixed value.

command so that the modem can learn the new speed.

, or s-register settings).

, or s-register).

. Refer to your modem documentation for the DCD settings used with your modem.

. Refer to your modem documentation for the DTR settings used with your modem.

to answer the call after one ring. Refer to your modem documentation for the settings used with your modem.

Supporting Dial-In Modems

The Cisco IOS software supports dial-in modems that use DTR to control the off-hook status of the telephone line. This feature is supported primarily on old-style modems, especially those in Europe. To configure the line to support this feature, use the following command in line configuration mode:

Command

Purpose

Configures a line for a dial-in modem.

command) passes before the modem raises the CTS signal, the line lowers the DTR signal and returns to the idle state.

Figure 2 EXEC Creation on a Line Configured for Modem Dial-In

Note The modem callin and modem cts-required line configuration commands are useful for SLIP operation. These commands ensure that when the line is hung up or the CTS signal drops, the line reverts from Serial Line Internet Protocol (SLIP) mode to normal interactive mode. These commands do not work if you put the line in network mode permanently.

command frees up CTS input for hardware flow control. Modern modems do not require the assertion of DTR to answer a phone line (that is, to take the line off-hook).

Testing the Modem Connection

command to request its attention. The modem should respond with “OK.” For example:

at

OK

command, perform the following steps:

.

EXEC command. The output should contain the following two lines:

Modem state: Idle

Modem hardware state: CTS noDSR DTR RTS

If the output displays “no CTS” for the modem hardware state, the modem is not connected, is not powered up, is waiting for data, or might not be configured for hardware flow control.

.

Table 1 Matching Line Speed with Transmission Rate

Modem Transmission Rate

(in bits per second)

Line Speed on the Access Server (in bits per second)

9600

38400

14400

57600

28800

115200

EXEC command. The line configuration fragment appears at the tail end of the output.

The following example shows that lines 7 through 9 are transmitting at 115200 bits per second (bps). Sixteen 28800-kbps modems are connected to a Cisco AS2511-RJ access server via a modem cable.

Router# show run

Building configuration...

Current configuration:

. . .

!

line 1 16

login local

modem InOut

speed 115200

transport input all

flowcontrol hardware

script callback callback

autoselect ppp

autoselect during-login

Step 4 The speeds of the modem and the access server are likely to be different. If so, switch off the modem, and then switch it back on. This action should change the speed of the modem to match the speed of the access server.

command to view your modem configuration.

Managing Telnet Sessions

connection).

Note Before attempting to allow inbound connections, make sure that you close all open connections to the modems attached to the access server. If you have a modem port in use, the modem will not accept a call properly.

is the line number to which the modem is connected. For example, to connect to the modem attached to line 1, enter the following command from an EXEC session on the access server:

Router# telnet 172.16.1.10 2001

Trying 172.16.1.10, 2001 ... Open

(attention) command set defined by the modem vendor.

Timesaver Use the ip host configuration command to simplify direct Telnet sessions with modems. The ip host command maps an IP address of a port to a device name. For example, the modem1 2001 172.16.1.10 command enables you to enter modem1 to initiate a connection with the modem, instead of repeatedly entering telnet 172.16.1.10 2001 each time you want to communicate with the modem.

Suspending Telnet Sessions:

command will return a state of idle. Terminating the Telnet session requires first suspending it, then disconnecting it.

To suspend a Telnet session, perform the following steps:

Step 1 Enter Ctrl-Shift-6 x to suspend the Telnet session:

- suspend keystroke -

Router#

Note Ensure that you can reliably issue the escape sequence to suspend a Telnet session. Some terminal emulation packages have difficulty sending the Ctrl-Shift-6 x sequence. Refer to your terminal emulation documentation for more information about escape sequences.

EXEC command to check the connection numbers of open sessions:

Router# where

Conn Host Address Byte Idle Conn Name

* 1 172.16.1.10 172.16.1.10 0 0 172.16.1.10

2 172.16.1.11 172.16.1.11 0 12 modem2

Step 3 When you have suspended a session with one modem, you can connect to another modem and suspend it:

Router# telnet modem2

Trying modem2 (172.16.1.11, 2002) ... Open

- suspend keystroke -

Router#

EXEC command:

Router# disconnect line 1

Closing connection to 172.16.1.10 [confirm] y

Router# disconnect line 2

Closing connection to 172.16.1.11 [confirm] y

Router#

Modem Troubleshooting Tips

Modem Troubleshooting Tips contains troubleshooting tips on modem access and control.

Table 2 Modem Troubleshooting Tips

Problem

Likely Cause

Connection refused.

Someone already has a connection to that port.

or

an EXEC is running on that port.

or

The modem failed to lower the carrier detect (CD) signal after a call disconnected, resulting in an EXEC that remained active after disconnect.

line configuration command) before making a reverse connection or configure the modem using an external terminal. As a last resort, disconnect the modem, clear the line, make the Telnet connection, and then attach the modem. The prevents a misconfigured modem from denying you line access.

Connection appears to hang.

Try entering “^U” (clear line), “^Q” (XON), and press Return a few times to try to establish terminal control.

EXEC does not come up; autoselect is on.

Press Return to enter EXEC.

Modem does not hang up after entering quit.

The modem is not receiving DTR information, or you have not set up modem control on the router.

Interrupts another user session when you dial in.

The modem is not dropping CD on disconnect, or you have not set up modem control on the router.

Connection hangs after entering “+++” on the dialing modem, followed by an ATO.

The answering modem saw and interpreted the “+++” when it was echoed to you. This is a bug in the answering modem, common to many modems. There may be a switch to work around this problem; check the modem’s documentation.

Losing data.

You may have Hardware Flow Control only on for either the router’s line (DTE) or the modem (DCE). Hardware Flow Control should be on for both or off for both, but not for only one.

Using MDCE.

Turn MDCE into an MMOD by moving pin 6 to pin 8 because most modems use CD and not DSR to indicate the presence of carrier. You can also program some modems to provide carrier info via DSR.

Checking Other Modem Settings

This section defines other settings that might be needed or desirable, depending on your modem.

Error correction can be negotiated between two modems to ensure a reliable data link. Error correction standards include Link Access Procedure for Modems (LAPM) and MNP4. V.42 error correction allows either LAPM or MNP4 error correction to be negotiated. Modems differ in the way they enable error correction. Refer to your modem documentation for the error correction methods used with your modem.

and MNP5. Modems differ in the way they enable data compression. Refer to your modem documentation for the data compression settings used with your modem.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2001-2008 Cisco Systems, Inc. All rights reserved.

Modem Signal and Line States

First Published: May 8, 2001

Last Updated: May 14, 2009

This chapter contains information on how to configure automatic dialing for modems and provides illustrations describing modem signal and line states.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the “Feature Information for Modem Signal and Line State” section.

. An account on Cisco.com is not required.

Contents

- Information About Signal and Line State Diagrams

- How to Configure Modem Signal and Line States

- Additional References

- Feature Information for Modem Signal and Line State

Information About Signal and Line State Diagrams

Signal and line state diagrams accompany some of the tasks in the following sections to illustrate how the modem control works. The following diagrams are described here:

- EXEC and Daemon Creation on a Line with No Modem Control

- EXEC Creation on a Line Configured for a High-Speed Modem

- EXEC and Daemon Creation on a Line for Incoming and Outgoing Calls

- EXEC and Daemon Creation on a Line Configured for Continuos CTS

- Daemon Creation on a Line Configured for Modem Dial-Out

EXEC and Daemon Creation on a Line with No Modem Control

The diagrams show two processes:

- The “create daemon” process creates a tty daemon that handles the incoming network connection.

- The “create EXEC” process creates the process that interprets user commands. (See Figure 1 through Figure 5.)

EXEC command) is listed next to the box. Events that change that state appear in italics along the event path, and actions that the software performs are described within ovals.

Figure 1 illustrates line states when no modem control is set. The DTR output is always high, and CTS and RING are completely ignored. The Cisco IOS software starts an EXEC session when the user types the activation character. Incoming TCP connections occur instantly if the line is not in use and can be closed only by the remote host.

Figure 1 EXEC and Daemon Creation on a Line with No Modem Control

EXEC Creation on a Line Configured for a High-Speed Modem

process with a high-speed dialup modem. When the Cisco IOS software detects a signal on the RING input of an idle line, it starts an EXEC or autobaud process on that line. If the RING signal disappears on an active line, the Cisco IOS software closes any open network connections and terminates the EXEC facility. If the user exits the EXEC or the software terminates because of no user input, the line makes the modem hang up by lowering the DTR signal for 5 seconds. After 5 seconds, the modem is ready to accept another call.

Figure 2 EXEC Creation on a Line Configured for a High-Speed Modem

EXEC and Daemon Creation on a Line for Incoming and Outgoing Calls

line configuration command described in the section “Automatically Answering a Modem”. If the line is activated by an incoming TCP connection, the line functions similarly to lines not used with modems.

Figure 3 EXEC and Daemon Creation on a Line for Incoming and Outgoing Calls

Note If your system incorporates dial-out modems, consider using access lists to prevent unauthorized use.

EXEC and Daemon Creation on a Line Configured for Continuos CTS

command operating in the context of a continuous CTS signal. This form of modem control requires that the CTS signal be high for the entire session. If CTS is not high, the user input is ignored and incoming connections are refused (or sent to the next line in a rotary group).

Figure 4 EXEC and Daemon Creation on a Line Configured for Continuous CTS

Daemon Creation on a Line Configured for Modem Dial-Out

line configuration command, the software lowers the DTR signal and drops the connection.

Figure 5 Daemon Creation on a Line Configured for Modem Dial-Out

How to Configure Modem Signal and Line States

To configure modem signal and line states, complete the tasks in the following sections:

- Supporting EXEC Restarts Triggered Via the Clear to Send (CTS) Hardware Line State

- Automatically Answering a Modem

- Supporting Dial-In and Dial-Out Connections

- Configuring a Line Timeout Interval

- Closing Modem Connections

- Configuring a Line to Disconnect Automatically

- Supporting Reverse Modem Connections and Preventing Incoming Calls

Supporting EXEC Restarts Triggered Via the Clear to Send (CTS) Hardware Line State

command enables the router to react to a CTS drop from the remote device, and to clear any existing EXEC session.

The router reacts to a CTS drop from a connected asynchronous device. When a CTS drop is detected, the existing EXEC session is cleared and there is no need to wait for a timeout. This method improves the speed EXEC recovery by using hardware signals.

Note Use this feature with an asynchronous serial device that relies only on CTS for flow control. The CTS performs a role similar to that of on-hook and off-hook functionality.

command in line configuration mode.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Enters line configuration mode for the line number specified.

Step 4

Configures the router to react on a CTS drop from the remote device, and to clear an existing EXEC session.

Configuring Automatic Dialing

command enables the router to initiate automatic dialin.

With the dialup capability, you can set a modem to dial the phone number of a remote router automatically. This feature offers cost savings because phone line connections are made only when they are needed—you pay for using the phone line only when there is data to be received or sent.

command causes a line to raise DTR signal only when there is an outgoing connection (such as reverse Telnet, NetWare Asynchronous Support Interface (NASI), or DDR), rather than leave DTR raised all the time. When raised, DTR potentially tells the modem that the router is ready to accept a call.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Enters line configuration mode for the line number specified.

Step 4

Configures a line to initiate automatic dialing.

Automatically Answering a Modem

command allows the router to configure a line to answer a modem automatically.

You also can configure the modem to answer the telephone on its own (as long as DTR is high), drop connections when DTR is low, and use its Carrier Detect (CD) signal to accurately reflect the presence of carrier. (Configuring the modem is a modem-dependent process.)

command in line configuration mode.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Enters line configuration mode for the line number specified.

Step 4

Configures a line to automatically answer a modem.

You can turn on modem hardware flow control independently to respond to the status of router CTS input. Wire CTS to whatever signal the modem uses for hardware flow control. If the modem expects to control hardware flow in both directions, you might also need to wire modem flow control input to some other signal that the router always has high, such as the DTR signal.

Supporting Dial-In and Dial-Out Connections

command enables the router to configure a line for both incoming and outgoing calls.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Enters line configuration mode for the line number specified.

Step 4

Configures a line for both incoming and outgoing calls.

Configuring a Line Timeout Interval

command enables the router to change the interval that the Cisco IOS software waits for the CTS signal after raising the DTR signal in response to the DSR (the default is 15 seconds).

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Enters line configuration mode for the line number specified.

Step 4

Configures a line for both incoming and outgoing calls.

Note The DSR signal is called RING on older ASM-style chassis.

Closing Modem Connections

Note The modem cts-required command was replaced by the modem printer command in Cisco IOS Release 12.2.

enables the router to configure a line to close connections from a user’s terminal when the terminal is turned off and to prevent inbound connections to devices that are out of service.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Enters line configuration mode for the line number specified.

Step 4

Configures a line to close connections.

Configuring a Line to Disconnect Automatically

command enables the router to configure automatic line disconnect.

command when the last connection closes. This feature is useful for UNIX-to-UNIX copy program (UUCP) applications because UUCP scripts cannot issue a command to hang up the telephone. This feature is not used often.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Enters line configuration mode for the line number specified.

Step 4

Configures automatic line disconnect.

Supporting Reverse Modem Connections and Preventing Incoming Calls

In addition to initiating connections, the Cisco IOS software can receive incoming connections. This capability allows you to attach serial and parallel printers, modems, and other shared peripherals to the router or access server and drive them remotely from other modem-connected systems. The Cisco IOS software supports reverse TCP, XRemote, and local-area transport (LAT) connections.

.

command enables the router to configure the Cisco IOS software to function somewhat like a modem, and prevents the incoming calls.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Enters line configuration mode for the line number specified.

Step 4

Configures a line for reverse connections and prevents incoming calls.

Additional References

The following sections provide references related to the Modem Signal and Line State feature.

Related Documents

Related Topic

Document Title

Modem Configuration Commands

Modem Configuration and Management

Standards

Standard

Title

None

MIBs

MIB

MIBs Link

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

RFCs

RFC

Title

None

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

Command Reference

.

- modem cts-alarm

- modem dtr-active

- modem dialin

- modem inout

- modem answer-timeout

- modem cts-required

- modem callout

Feature Information for Modem Signal and Line State

lists the release history for this feature.

Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.

. An account on Cisco.com is not required.

Note Table 1 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.

Table 1 Feature Information for Modem Signal and Line State

Feature Name

Releases

Feature Information

Automatic Modem Configuration

12.2SX

Automatic Modem Configuration can issue initialization strings automatically for most types of modems externally attached to the access server.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

© 2001-2009 Cisco Systems, Inc. All rights reserved.

Creating and Using Modem Chat Scripts

This chapter describes how to create and use modem chat scripts. These tasks are presented in the following main sections:

- Chat Script Overview

- How To Configure Chat Scripts

- Using Chat Scripts

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

publication. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

Chat Script Overview

Chat scripts are strings of text used to send commands for modem dialing, logging in to remote systems, and initializing asynchronous devices connected to an asynchronous line.

Note On a router, chat scripts can be configured only on the auxiliary port.

A chat script must be configured to dial out on asynchronous lines. You also can configure chat scripts so that they can be executed automatically for other specific events on a line, or so that they are executed manually.

Each chat script is defined for a different event. These events can include the following:

- Line activation

- Incoming connection initiation

- Asynchronous dial-on-demand routing (DDR)

- Line resets

- Startup

Note Outbound chat scripts are not supported on lines where modem control is set for inbound activity only using the modem dialin command.

How To Configure Chat Scripts

The following tasks must be performed before a chat script can be used:

- Define the chat script in global configuration mode using the chat-script command.

- Configure the line so that a chat script is activated when a specific event occurs (using the script line configuration command), or start a chat script manually (using the start-chat privileged EXEC command).

To configure a chat script, perform the tasks in the following sections:

- Understanding Chat Script Naming Conventions (Required)

- Creating a Chat Script (Required)

- Configuring the Line to Activate Chat Scripts (Required)

- Manually Testing a Chat Script on an Asynchronous Line (Optional)

See the section “Using Chat Scripts” later in this chapter for examples of how to use chat scripts.

Understanding Chat Script Naming Conventions

When you create a script name, include the modem vendor, type, and modulation, separated by hyphens, as follows:

telebit-t3000-v32bis

Note Adhering to the recommended naming convention allows you to specify a range of chat scripts by using partial names in UNIX-style regular expressions. The regular expressions are used to match patterns and select chat scripts to use. This method is particularly useful for dialer rotary groups on an interface that dials multiple destinations. Regular expressions are described in the “Regular Expressions” appendix in the Cisco IOS Terminal Services Configuration Guide.

Creating a Chat Script

We recommend that one chat script (a “modem” chat script) be written for placing a call and that another chat script (a “system” or “login” chat script) be written to log in to remote systems, where required.

To define a chat script, use the following command in global configuration mode:

Command

Purpose

Creates a script that will place a call on a modem, log in to a remote system, or initialize an asynchronous device on a line.

portion of the script).

Chat String Escape Key Sequences

.

Table 1 Chat Script Send String Escape Sequences

Escape Sequence

Description

\

Sends the ASCII character with its octal value.

\\

Sends a backslash (\) character.

\”

double quotes).

\c

Suppresses a new line at the end of the send string.

\d

Delays for 2 seconds.

\K

Inserts a BREAK.

\n

Sends a newline or linefeed character.

\N

Sends a null character.

\p

Pauses for 0.25 second.

\q

Reserved, not yet used.

\r

Sends a return.

\s

Sends a space character.

\t

Sends a tab character.

\T

Replaced by phone number.

“ ”

Expects a null string.

BREAK

Causes a BREAK. This sequence is sometimes simulated with line speed changes and null characters. May not work on all systems.

EOT

Sends an end-of-transmission character.

Adding a Return Key Sequence

) as part of your chat script:

ssword:-/r-ssword

.)

Chat String Special-Case Script Modifiers

for examples.

Table 2 Special-Case Script Modifiers

Special Case

Function

Designates a string whose presence in the input indicates that the chat script has failed. (You can have as many active abort entries as you like.)

5 seconds, and a timeout of 60 seconds is recommended for V.90 modems.

For example, if a modem reports BUSY when the number dialed is busy, you can indicate that you want the attempt stopped at this point by including ABORT BUSY in your chat script.

Note If you use the expect-send pair ABORT SINK instead of ABORT ERROR, the system terminates abnormally when it encounters SINK instead of ERROR.

Configuring the Line to Activate Chat Scripts

line configuration command. To start a chat script manually at any point, see the following section, “Manually Testing a Chat Script on an Asynchronous Line.”

To define a chat script to start automatically when a specific event occurs, use one of the following commands in line configuration mode:

Command

Purpose

Starts a chat script on a line when the line is activated (every time a command EXEC is started on the line).

Starts a chat script on a line when a network connection is made to the line.

Specifies a modem script for DDR on a line.

Starts a chat script on a line whenever the line is reset.

Starts a chat script on a line whenever the system is started up.

1.The regexp argument is a regular expression that is matched to a script name that has already been defined using the chat-script command.

1.The regexp argument is a regular expression that is matched to a script name that has already been defined using the chat-script command.

2.Do not use the script reset or script startup commands to configure a modem; instead use the modem autoconfigure command.

2.Do not use the script reset or script startup commands to configure a modem; instead use the modem autoconfigure command.

Note Outbound chat scripts are not supported on lines where modem control is set for inbound activity only (using the modem dialin command).

Manually Testing a Chat Script on an Asynchronous Line

To test a chat script on any line that is currently not active, use the following commands in privileged EXEC mode:

Command

Purpose

Step 1

Router# debug chat line number

Starts detailed debugging on the specified line.

Step 2

Router# start-chat regexp [ line-number [ dialer-string ]]

Starts a chat script on any asynchronous line.

If you do not specify the line number, the script runs on the current line. If the line specified is already in use, you cannot start the chat script. A message appears indicating that the line is already in use.

Using Chat Scripts

The following sections provide examples of how to use chat scripts:

- Generic Chat Script Example

- Traffic-Handling Chat Script Example

- Modem-Specific Chat Script Examples

- Dialer Mapping Example

- System Login Scripts and Modem Script Examples

Generic Chat Script Example

The following example chat script includes a pair of empty quotation marks (“ ”), which means “expect anything,” and \r, which means “send a return”:

" " \r "name:" "myname" "ord":" "mypassword" ">" "slip default"

Traffic-Handling Chat Script Example

or the system script cisco. If there is no match for either the modem script or the system script, you will see a “no matching chat script found” message.

interface dialer 1

! v.32 rotaries are in rotary 1.

dialer rotary-group 1

! Use v.32 generic script.

dialer map ip 10.0.0.1 modem-script .*-v32 system-script cisco 1234

Modem-Specific Chat Script Examples

The following example shows line chat scripts being specified for lines connected to Telebit and US Robotics modems:

! Some lines have Telebit modems.

line 1 6

script dialer telebit.*

! Some lines have US Robotics modems.

line 7 12

script dialer usr.*

Dialer Mapping Example

The following example shows a modem chat script called dial and a system login chat script called login:

chat-script dial ABORT ERROR "" "AT Z" OK "ATDT \T" TIMEOUT 60 CONNECT \c

chat-script login ABORT invalid TIMEOUT 60 name: myname word: mypassword ">" "slip default"

interface async 10

dialer in-band

dialer map ip 10.55.0.1 modem-script dial system-script login 96837890

Figure 1 illustrates the configuration.

Figure 1 Chat Script Configuration and Function

- The configuration is on Router A.

- The modem chat script dial is used to dial out to the modem at Router B.

- The system login chat script login is used to log in to Router B.

- The phone number is the number of the modem attached to Router B.

- The IP address in the dialer map command is the address of Router B.

lists the functions that are implemented with each expect-send pair in the modem script called dial.

Table 3 Example Modem Script Execution

Expect and Send Pair

Implementation

Ends the script execution if the text “ERROR” is found. (You can have as many active abort entries as you like.)

Without expecting anything, sends an “AT Z” command to the modem. (Note the use of quotation marks to allow a space in the send string.)

Waits to see “OK.” Sends “ATDT 96837890.”

TIMEOUT 60

Waits up to 60 seconds for next expect string.

Expects “connect,” but does not send anything. (Note that \c is effectively nothing; “ ” would have indicated nothing followed by a carriage return.)

lists the functions that are executed with each expect-send pair in the system script called login.

Table 4 Example System Script Execution

Expect and Send Pair

Implementation

ABORT invalid

Ends the script execution if the message “invalid username or password” is displayed.

TIMEOUT 60

Waits up to 60 seconds.

Waits for “name:” and sends username. (Using just “name:” will help avoid any capitalization issues.)

Waits for “word:” and sends the password.

“>” “slip default”

Waits for the > prompt and places the line into Serial Line Internet Protocol (SLIP) mode with its default address.

System Login Scripts and Modem Script Examples

command.

If there is traffic for IP address 10.2.3.4, the router will dial the 91800 number using the usrobotics-v32 script, matching the regular expression in the modem chat script. Then the router will run the unix-slip chat script as the system script to log in.

If there is traffic for 10.3.2.1, the router will dial 8899 using usrobotics-v32, matching both the modem script and modem chat script regular expressions. The router will then log in using the cisco-compressed script.

! Script for dialing a usr v.32 modem:

chat-script usrobotics-v32 ABORT ERROR "" "AT Z" OK "ATDT \T" TIMEOUT 60 CONNECT \c

!

! Script for logging into a UNIX system and starting up SLIP:

chat-script unix-slip ABORT invalid TIMEOUT 60 name: billw word: wewpass ">" "slip default"

!

! Script for logging into a Cisco access server and starting up TCP header compression:

chat-script cisco-compressed...

!

line 15

script dialer usrobotics-*

!

interface async 15

dialer map ip 10.2.3.4 system-script *-v32 system-script cisco-compressed 91800

dialer m

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2001-2008 Cisco Systems, Inc. All rights reserved.

Cisco Modem User Interface

Feature History

Release

Modification

12.2(4)T

This feature was introduced.

This document describes the Asynchronous Line Monitoring feature feature in Cisco IOS Release 12.2(4)T. It includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Configuration Tasks

- Monitoring and Maintaining the Asynchronous Line Monitoring feature

- Configuration Examples

- Command Reference

- Glossary

Feature Overview

The Asynchronous Line Monitoring feature feature enables Cisco routers to behave like a modem and be configured using standard Hayes modem commands.

Figure 1 shows a legacy data transfer configuration using X.25, modems, and telephone lines.

Figure 1 Legacy Data Transfer Equipment

With the Asynchronous Line Monitoring feature feature, a point of sale (POS) terminal, such as those used by gasoline service stations to charge customers for merchandise and services, can use high-speed Internet connections rather than slow-speed telephone connections to transfer data (see Figure 2).

Figure 2 Data Transfers Using the Asynchronous Line Monitoring feature

The user interface to the higher speed connection will not change when the Asynchronous Line Monitoring feature feature is used; the user interface will still appear as if the connection on the POS terminal is through a modem and a telephone line.

Although there are a wide variety of proprietary extensions to the Hayes modem commands, the Asynchronous Line Monitoring feature feature supports only a subset of the commands. This basic functionality is enhanced with Cisco-specific modem register settings, Telnet connection capability, and dial-related Cisco IOS commands.

Note Typically, parity and databits commands have no effect on modem lines without UART. However, since modem lines such as WIC-1AM and WIC-2AM are implemented though UART and use an internal UART, the parity and databits commands can be used to set async parity framing. The following commands may be used on WIC-AM modem cards (although changing the DTE speed and stopbits on these lines have no effect): parity, databits, stopbits, flowcontrol, speed, rxspeed, txspeed.

Benefits

The Asynchronous Line Monitoring feature feature allows Cisco routers to replace modems, and thereby update a slow telephone call-modem negotiation process with a high-speed Internet connection. Together, these features provide the following benefits:

- Reduced costs, because modems are no longer necessary.

- Increased connection speeds, because Internet connections are faster than modem connections.

Restrictions

The following Hayes modem features are not supported by the Asynchronous Line Monitoring feature:

- Modem autobaud detection

- Modem answer capability

- Modem fax features

- Synchronous traffic

- The Hayes modem escape sequence (,+++,)

Supported Platforms

- Cisco 1700 series

- Cisco 2600 series

- Cisco 3600 series

Platform Support Through Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Feature Navigator. Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image.

To access Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions at http://www.cisco.com/register.

Feature Navigator is updated when major Cisco IOS software releases and technology releases occur. As of May 2001, Feature Navigator supports M, T, E, S, and ST releases. You can access Feature Navigator at the following URL:

http://www.cisco.com/go/fn

Supported Standards, MIBs, and RFCs

Standards

None

MIBs

None

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

RFCs

None

Configuration Tasks

See the following sections for the configuration tasks for the Asynchronous Line Monitoring feature feature. Each task in the list is identified as either required or optional:

- Configuring the Telephone Number for the Asynchronous Line Monitoring feature Connection (required)

- Configuring a Line for the Asynchronous Line Monitoring feature (required)

- Entering Asynchronous Line Monitoring feature Mode from EXEC Mode (optional)

- Configuring Banners for the Hayes Information Mode Command (optional)

Configuring the Telephone Number for the Asynchronous Line Monitoring feature Connection

To configure the telephone number for the Asynchronous Line Monitoring feature feature, you must map the telephone number to the IP host where the connection will be made. To do so, use the following command in global configuration mode:

Command

Purpose

Maps a modem telephone number to an IP host address for use in Asynchronous Line Monitoring feature mode.

Configuring a Line for the Asynchronous Line Monitoring feature

command.)

Command

Purpose

Step 1

Selects the line to configure for the Asynchronous Line Monitoring feature feature and enters line configuration mode.

Step 2

Sets the number of stop bits sent per byte.

Step 3

Sets the asynchronous line bit rate.

Step 4

Sets line flow control.

Step 5

(Optional) Delays assertion of the data terminal ready (DTR) signal until a connection is established.

Step 6

command.

Note Typically, parity and databits commands have no effect on modem lines without UART. However, since modem lines such as WIC-1AM and WIC-2AM are implemented though UART and use an internal UART, the parity and databits commands can be used to set async parity framing. The following commands may be used on WIC-AM modem cards although changing the DTE speed and stopbits on these lines have no effect: parity, databits, stopbits, flowcontrol, speed, rxspeed, and txspeed.

Example configurations in the section “Configuration Examples” list additional commands that might also be entered for line configuration.

Entering Asynchronous Line Monitoring feature Mode from EXEC Mode

To enter the Cisco modem user interface from EXEC mode, use the following command in EXEC mode:

Command

Purpose

]

.

EXEC command to be automatically executed; see the section “Configuring a Line for the Asynchronous Line Monitoring feature” for the relevant task.

Configuring Banners for the Hayes Information Mode Command

To configure banners that are displayed in response to the Hayes information mode command, use the following command in global configuration mode:

Command

Purpose

.

.

Table 1 Cisco-Supported Hayes Modem Commands

Hayes Modem Commands

Description

command.

EXEC command.

global configuration command. For example:

ip host t555-1212 4023 10.0.0.51

command, as follows:

- The numbers 0 through 9

- Uppercase letters A through Z

- Lowercase letters a through z

- The . (period), - (hyphen), and _ (underscore) characters

No other characters (such as # or *) are accepted in the dial string, and unsupported characters are stripped before dialing occurs.

follow:

- 0 turns off command echo.

- 1 turns on command echo (default).

Hangup mode. A value of 0 or 1 closes the connection.

are the numbers 0 through 6.

Online mode. A value of 0 or 1 resumes the connection.

follow:

- 0 displays modem result codes (default).

- 1 inhibits modem result codes display (quiet mode).

Set selected register (S-register).

Note The standard Hayes modem S-register settings S0 through S53 are accepted by Cisco IOS software, but do not have any effect.

:

- S201—Command mode parity sniffing.

line configuration commands.

part of the command, while the data portion will be 8-bit transparent.

- S202—Output mask.

This setting allows mark parity to be unconditionally implemented for the command characters. The default value for S202 is 0 (no parity). The value 128 causes command characters to be sent with mark parity.

- S203—Connect delay.

. For example, a value of 300 sets a connect delay of 30 seconds. The default value is 0.

- S204—Connect code.

Allows the result code for a successful connection to be specified. The default is code 1 for the unextended mode, but you can configure one of the following numbers to display a selected line speed. For example, connection code 10 selects CONNECT 2400. By allowing the code to be expressed explicitly, you can allow for a “CONNECT 2400” response message to be displayed, regardless of the actual line speed.

is 0, or choose one of the following connection codes:

– 9—CONNECT 1200

– 10—CONNECT 2400

– 11—CONNECT 4800

– 12—CONNECT 9600

– 13—CONNECT 14400

– 14—CONNECT 19200

– 15—CONNECT 38400

– 16—CONNECT 57600

?

is the number of the S-register to query (S201 through S204, see the preceding list).

follow:

- 0 displays a short result report.

- 1 displays a long result report (default).

is any nonzero number, which appends /NONE to the connect message. Also see the preceding description for S-register S204, for changing the reported connection speed.

Reset to default configuration. Choose one of the following reset options:

- ATZ returns the Cisco modem user interface to its default state and re-executes the initialization string provided in the modemui command.

- ATZ99 returns to the standard Cisco IOS software user interface (EXEC) mode.

Verifying Asynchronous Line Monitoring feature Mode

To verify correct operation of the Asynchronous Line Monitoring feature feature, perform the following steps in EXEC mode:

command to enter Cisco modem user interface mode:

Router# modemui

command to start interactive Cisco modem user interface mode operation. The system replies with “OK” when you successfully enter the mode:

AT

OK

dial command. A successful connection displays the “CONNECT” message followed by the login prompt from the remote terminal:

ATDT4085551212

CONNECT

User Access Verification

Username:

Step 4 Enter the Cisco IOS escape sequence (by default this sequence is Ctrl^, X) to leave the connection and return to the Cisco modem user interface mode.

command. The Cisco IOS EXEC prompt reappears:

ATZ99

Router#

Verifying the Asynchronous Line Monitoring feature Telephone-to-IP-Address Map

command in EXEC mode to display the telephone number associated with the IP host. This command also displays default domain name, the style of name lookup service, a list of name server hosts, and the cached list of host names and addresses.

Router# show host

Default domain is not set

Name/address lookup uses domain service

Name servers are 255.255.255.255

Codes: u - unknown, e - expired, * - OK, ? - revalidate

t - temporary, p - permanent

Host Age Type Address(es)

*p p4085554567 0 IP 1.2.1.6

*p t4085551234 0 IP 1.2.1.5

Under the Host field, a “p” indicates a pulse-dialed modem telephone number, and a “t” indicates a tone-dialed modem telephone number. The IP address mapped to the telephone number appears under the “Address(es)” field.

Troubleshooting Tips

privileged EXEC command to start modem and EXEC debugging mode.

Monitoring and Maintaining the Asynchronous Line Monitoring feature

To monitor and maintain the Asynchronous Line Monitoring feature feature, use the following commands in EXEC mode, as needed:

Command

Purpose

Displays the default domain name, the style of name lookup service, a list of name server hosts, and the cached list of host names and addresses.

Displays the status of TCP connections, and lists the telephone number mapped to the IP host.

Displays information about the active lines on the router.

Configuration Examples

This section provides the following configuration examples:

- Automatic Connection Configuration Example

- Asynchronous Tunnel Termination Configuration Example

- Banner Setup and Display Example

Automatic Connection Configuration Example

The following example shows how to configure the Asynchronous Line Monitoring feature shown in Figure 3.

Figure 3 Asynchronous Line Monitoring feature Configuration

command in the following “Client Router Configuration” output).

Client Router Configuration

ip host t4155551234 192.168.33.15

!

line 35

login authentication modem

modem dialin delay

stopbits 1

speed 2400

flowcontrol hardware

transport input none

autocommand modemui ats203=20

Host Router Configuration

aaa new-model

aaa authentication login modem none

!

ip host t4085551234 1.2.1.5

!

interface async 129

ip address 1.2.1.5 255.255.255.0

encapsulation ppp

async dynamic address

async dynamic routing

async mode dedicated

pulse-time 3

Asynchronous Tunnel Termination Configuration Example

The following example shows a configuration where a destination host router terminates an asynchronous tunnel from the client router. The connection to the final destination is also an asynchronous connection (see Figure 4).

Figure 4 Asynchronous Tunnel Configuration

EXEC command.

Client Router Configuration

!

ip host t4155551234 4017 121.12.33.15

!

line 35

login authentication modem

modem dialin delay

stopbits 1

speed 2400

flowcontrol hardware

transport input none

autocommand ats203=20

Host Router Configuration

!

line 17

login authentication asynctunnels

modem host

transport input all

stopbits 1

speed 2400

flowcontrol hardware

no exec

Banner Setup and Display Example

modem command:

modemui-version / Telebit T3000 Modem, Version 1.5 /

To display the banner, perform the following steps:

command to enter Cisco modem user interface mode:

Router# modemui

command:

ATI6

Telebit T3000, Version 1.5

dial command. A successful connection displays the “CONNECT” message followed by the login prompt from the remote terminal:

ATDT4085551212

CONNECT

User Access Verification

Username:

Step 4 To leave the connection and return to Cisco modem user interface mode, either enter the Cisco IOS escape sequence (by default this sequence is Ctrl^, X), or log out of an active terminal session.

command. The Cisco IOS EXEC prompt reappears:

ATZ99

Router#

Command Reference

.

New Commands

- modemui

- modemui-version

Modified Commands

- ip host

- modem dialin

- show hosts

Glossary

command turns off command echoing.

—Any modem that recognizes Hayes modem commands. Hayes Microcomputer Products has developed a language called the AT command set for controlling modems that has become a de facto modem industry standard.

—See POS.

—See POS.

—point of service or point of sale. A terminal such as those used by gasoline service stations to charge customers for merchandise and services. A POS is a PC with an internal modem and software

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

© 2001-2008 Cisco Systems, Inc. All rights reserved.

Modem Script and System Script Support in Large-Scale Dial-Out

This feature module describes the Modem Script and System Script Support in Large-Scale Dial-Out feature and includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Configuration Tasks

- Monitoring and Maintaining Large-Scale Dial-Out Sessions

- Configuration Examples

- Command Reference

- Appendix

- Glossary

Feature Overview

Modem connection and system login chat scripts are often used when asynchronous dial-on-demand routing (DDR) is configured. Currently, however, the large-scale dial-out network architecture does not allow chat scripts for a particular session to be passed through the network. Cisco IOS Release 12.2(2)T allows modem and system chat scripts to pass through large-scale dial-out networks by allocating two new authentication, authorization, and accounting (AAA) attributes for outbound service.

The AAA attributes define specific AAA elements in a user profile. Large-scale dial-out supports Cisco attribute-value (AV) pairs and TACACS+ attributes. The Modem Script and System Script Support in Large-Scale Dial-Out feature provides two new outbound service attributes for passing chat scripts: modem-script and system-script.

Benefits

The Modem Script and System Script Support in Large-Scale Dial-Out feature allows users to use modem and system chat scripts by linking them to AAA service outbound attributes for use by Cisco network access servers in large-scale dial-out networks.

Related Documents

- Cisco IOS Dial Technologies Configuration Guide, Release 12.2

- Cisco IOS Security Configuration Guide , Release 12.2

- CiscoSecure ACS for Windows NT User Guide 2.0

Supported Platforms

The Asynchronous Line Monitoring feature feature was developed for and tested on several Cisco device platforms. Check Feature Navigator for the feature sets in which the Asynchronous Line Monitoring feature is available.

Determining Platform Support Through Cisco Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Cisco Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.

.

Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:

Supported Standards, MIBs, and RFCs

Standards

No new or modified standards are supported by this feature.

MIBs

No new or modified MIBs are supported by this feature.

.

RFCs

No new or modified RFCs are supported by this feature.

Configuration Tasks

See the following sections for configuration tasks for the Modem Script and System Script Support in Large-Scale Dial-Out feature. Each task in the list is identified as either optional or required.

- Creating the Dial-Out Profile (required)

- Creating the Chat Script (required)

- Verifying Modem and System Chat Scripts with Large-Scale Dial-Out (optional but recommended)

.

Creating the Dial-Out Profile

To specify a name for the modem script and, if needed, a system script using cisco-avpair attributes for outbound service, use the following syntax to enter these attributes in the dial-out profile:

cisco-avpair = "outbound:modem-script=script-name"

cisco-avpair = "outbound:system-script=script-name"

To specify a name for the modem script and, if needed, a system script using TACACS+ attributes for outbound service, use the following syntax to enter these attributes in the dial-out profile:

service = outbound {

modem-script = script-name

system-script = script-name

}

Timesaver Remember that the dial-out profile name must have the characters “-out” appended to it and that the only required attribute for a profile is the Cisco AV pair outbound:dial-number.

See the section “Dial-Out Profile Examples” for examples of dial-out profiles.

Creating the Chat Script

To configure the modem or system script name in the Cisco network access server (NAS), use the following command in global configuration mode:

Command

Purpose

Provides commands to dial a modem and commands to log on to remote systems when using DDR.

See the section “Chat Script Example” for an example of a chat script that works with a dial-out-profile.

Verifying Modem and System Chat Scripts with Large-Scale Dial-Out

command. See the “Verification Example” for a sample of the output from this command.

Monitoring and Maintaining Large-Scale Dial-Out Sessions

To monitor and maintain large-scale dial-out sessions, use the following commands in EXEC mode as needed:

Command

Purpose

Removes all dialer sessions and disconnects links.

Displays configuration information and information about AAA/TACACS+ authorization.

Displays all dialer sessions.

Configuration Examples

This section provides the following configuration examples:

- Dial-Out Profile Examples

- Chat Script Example

- Verification Example

Dial-Out Profile Examples

The following is an example of a Cisco AV pair dial-out profile named “evergreen” that defines a modem script named “dialer-script”:

evergreen-out Password = "cisco",

User-Service-Type = Outbound-User

cisco-avpair = "outbound:dial-number=5551212",

cisco-avpair = "outbound:addr=5.1.1.1",

cisco-avpair = "outbound:send-secret=cisco",

cisco-avpair = "outbound:modem-script=dialer-script"

The following is an example of how to define the same profile for TACACS+:

user = evergreen-out

{

service = outbound {

dial-number = 5551212

addr = 5.1.1.1

send-secret = cisco

modem-script = dialer-script

}

service = ppp protocol = ip {

default attribute = permit

}

}

Chat Script Example

The following example creates a chat script for the Cisco NAS that references the dialer-script modem script created in the dial-out profile:

chat-script dialer-script "" AT OK ATDT\T TIMEOUT 60 CONNECT

Verification Example

privileged EXEC command:

00:01:07: %LSDialout: temporary debug to verify the data integrity

00:01:07: dial number = 5551212

00:01:07: dialnum_count = 1

00:01:07: force_56 = 0

00:01:07: routing = 0

00:01:07: data_svc = -1

00:01:07: port_type = -1

00:01:07: map_class =

00:01:07: modem_script = dialer-script

00:01:07: system_script =

00:01:07: ip_address = 5.1.1.1

00:01:07: send_secret = cisco

00:01:07: send_auth = -1

00:01:07: send_name =

00:01:07: class =

Command Reference

.

Appendix

The following new Cisco AV pairs and TACACS+ attributes are added to the large-scale dial outbound service attributes:

Modem Script Attribute

Specifies a name for the modem script.

Cisco AV Pair:

cisco-avpair = "outbound:modem-script=VALUE"

TACACS+ Support:

service = outbound {

modem-script = VALUE

}

Value:

Modem script name that you assign.

System Script Attribute

Specifies a name for the system script.

Cisco AV Pair:

cisco-avpair = "outbound:system-script=VALUE"

TACACS+ Support:

service = outbound {

system-script = VALUE

}

Value:

System script name that you assign.

Glossary

—authentication, authorization, and accounting. Suite of network security services that provide the primary framework through which access control can be set up on your Cisco router or access server.

—Data items sent between a network access server and a daemon that are used to direct AAA activities.

—See AAA.

—Strings of text used to send commands for modem dialing, logging in to remote systems, and initializing asynchronous devices connected to an asynchronous line.

—Attributes that define specific AAA elements in a user profile. Large-scale dial-out supports a subset of Ascend AV pairs, RADIUS attributes, and a map class attribute providing outbound dialing services.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2001-2008 Cisco Systems, Inc. All rights reserved.

Leased and Switched BRI Interfaces for

ETSI NET3

Feature History

Release

Modification

12.2(4)T

This feature was introduced on the Cisco 800 series routers.

This document describes the Leased and Switched BRI Interfaces for ETSI NET3 feature. It includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Prerequisites

- Configuration Tasks

- Monitoring and Maintaining Leased and Switched BRI Interfaces for ETSI NET3

- Configuration Examples

- Command Reference

Feature Overview

1. In most BRI configurations, both B channels of a leased-line service are used as point-to-point leased lines with the D channel disabled. Data transmission over the B channels is no different than data transmission over point-to-point leased lines.

2. A new feature available in Cisco IOS Release 12.2(4)T, Leased and Switched BRI Interfaces for ETSI NET3, allows one BRI B channel on a European Telecommunications Standards Institute (ETSI) NET3 switch to be configured as a leased line, and the second B channel to be configured as a standard ISDN or dial interface and used as a switched channel to the Public Switched Telephone Network (PSTN). When the Leased and Switched BRI Interfaces for ETSI NET3 feature is configured, one B channel functions as a point-to-point 64-kbps leased line and the other B channel functions as a circuit-switched channel using the D channel to provide the signaling features available for the ETSI NET3 signaling protocol.

Benefits

The Leased and Switched BRI Interfaces for ETSI NET3 feature allows Internet service providers to split one ISDN line into a leased-line interface and a dialer interface, thereby increasing connection capability without increasing cost.

Restrictions

The following restrictions apply to the Leased and Switched BRI Interfaces for ETSI NET3 feature:

- Only the ETSI NET3 signaling protocol is supported at a line speed of 64 kbps.

- Only one ISDN call can be active at any time, and the call must verify that the leased line is not used to bring up a second call.

- The ETSI NET3 switch cannot be configured for a leased line when the U interface is used instead of the S/T interface; doing so prevents the line protocol from coming up.

Related Documents

- Cisco IOS Dial Technologies Command Reference , Release 12.2

- Cisco IOS Dial Technologies Configuration Guide , “ISDN Configuration” part, Release 12.2

Supported Platforms

- Cisco 800 series

Platform Support Through Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Feature Navigator. Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image.

To access Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions at http://www.cisco.com/register.

Feature Navigator is updated when major Cisco IOS software releases and technology releases occur. As of May 2001, Feature Navigator supports M, T, E, S, and ST releases. You can access Feature Navigator at the following URL:

http://www.cisco.com/go/fn

Supported Standards, MIBs, and RFCs

Standards

None

MIBs

The fillin_isdnBearerEntry() – isdnBearerTable manipulation MIB function is supported. See the “RFCs” section for more information.

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

RFCs

- RFC 2127, ISDN Management Information Base using SMIv2

RFC 2127 states that the following be reported for the leased line B channel: The isdnBearerTable MIB entry for the leased line B channel will need to be altered, specifically the value of isdnBearerChannelType MIB will be set to leased(2). This alteration involves a function in isdn/sr_ietf_isdmib.c, namely the fillin_isdnBearerEntry() — isdnBearerTable manipulation MIB function.

- RFC 1573, Evolution of the Interfaces Group of MIB-II

RFC 1573 makes no explicit mention of changes to the ifEntry for a B channel set to leased line. It is proposed that the ifAdminStatus and ifOperStatus functions remain in the UP(1) state.

Prerequisites

, Release 12.2.

Configuration Tasks

See the following sections for configuration tasks for the Leased and Switched BRI Interfaces for ETSI NET3 feature. Each task in the list is identified as either required or optional:

- Configuring Leased and Switched BRI Interfaces for ETSI NET3 (required)

- Verifying Leased and Switched BRI Interfaces for ETSI NET3 (optional)

Configuring Leased and Switched BRI Interfaces for ETSI NET3

To configure a BRI for both an ISDN connection and leased-line service, use the following commands in global configuration mode:

Command

Purpose

Step 1

Configures the ETSI NET3 BRI switch type.

Step 2

}

Splits a line for both ISDN and 64-kbps leased-line service.

Verifying Leased and Switched BRI Interfaces for ETSI NET3

Note In the following verification procedure, BRI channel B1(the BRI0:1 interface) is configured for leased-line service and channel B2 (the BRI0:2 interface) is configured for ISDN.

To verify that each BRI channel is configured correctly, perform the following steps:

EXEC command and check the value in The Free Channel Mask field to verify that only one channel has been allocated for ISDN. The Free Channel Mask field displays 0x80000000 when there is an active call. If no call is active, The Free Channel Mask field displays 0x80000001 and 0x80000002 for the B1 and B2 leased line configurations, respectively.

Router# show isdn status

Global ISDN Switchtype = basic-net3

ISDN BRI0 interface

dsl 0, interface ISDN Switchtype = basic-net3

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 124, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED

I_Queue_Len 0, UI_Queue_Len 0

Layer 3 Status:

1 Active Layer 3 Call(s)

CCB:callid=8001, sapi=0, ces=1, B-chan=2, calltype=DATA

Active dsl 0 CCBs = 1

The Free Channel Mask: 0x80000000

Total Allocated ISDN CCBs = 1

EXEC command to display dialer interface statistics. Check that there is no entry for the BRI0:1 interface in the display:

Router# show dialer

BRI0 - dialer type = ISDN

Dial String Successes Failures Last DNIS Last status

0 incoming call(s) have been screened.

0 incoming call(s) rejected for callback.

BRI0:2 - dialer type = ISDN

Idle timer (120 secs), Fast idle timer (20 secs)

Wait for carrier (30 secs), Re-enable (15 secs)

Dialer state is idle

Di1 - dialer type = DIALER PROFILE

Idle timer (6000 secs), Fast idle timer (20 secs)

Wait for carrier (30 secs), Re-enable (15 secs)

Dialer state is idle

Number of active calls = 0

Dial String Successes Failures Last DNIS Last status

5552000 0 0 never - Default

Troubleshooting Tips

To test the BRI configurations, use the following commands in EXEC mode, as needed:

Command

Purpose

Checks Layer 1 of the BRI.

Checks Layer 2 of the BRI.

Checks dialer events on the BRI.

Checks call control events on the BRI.

Checks Layer 3 of the BRI.

commands.

Monitoring and Maintaining Leased and Switched BRI Interfaces for ETSI NET3

To monitor and maintain the BRI configurations, use the following commands in EXEC mode, as needed:

Command

Purpose

Displays Layer 1, Layer 2, and Layer 3 status of the D channel and channel mask information.

Displays status of the ISDN BRI channel configured as either a leased line or dialer B-channel interface.

Displays status of the ISDN BRI channel configured as a dialer interface.

Configuration Examples

This section provides an example of how to configure the Leased and Switched BRI Interfaces for ETSI NET3 feature.

Leased and Switched BRI Interfaces for ETSI NET3 Example

The following example configures BRI channel B2 for 64-kbps leased-line service and channel B1 for ISDN service:

isdn leased-line bri0/0 b2

!

interface bri0/0

ip address 10.1.1.1 255.255.255.0

no ip address

dialer pool-member 1

interface bri0/0:2

ip address 10.1.1.2 255.255.255.0

encapsulation ppp

no ip address

Command Reference

.

- isdn leased-line bri

Glossary

—See ETSI.

—European Telecommunications Standards Institute. Organization created by European Post, Telephone, and Telegraph (PTT) groups and the European Community (EC) to propose telecommunications standards for Europe.

—Transmission line reserved by a communications carrier for the private use of a customer.

—General term applied to an electronic or mechanical device that allows a connection to be established as necessary and terminated when there is no longer a session to support.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2001-2008 Cisco Systems, Inc. All rights reserved.

ISDN BCAC and Round-Robin Channel Selection Enhancements

The ISDN BCAC and Round-Robin Channel Selection Enhancements feature allows more dynamic control of the ISDN B channels by providing additional B-Channel Availability Control (BCAC) functionality for configuring message signaling, and an enhanced channel selection scheme that adds round-robin configuration to the existing ascending and descending channel selection schemes already available.

Feature Specifications for the ISDN BCAC Enhancements

Feature History

Release

Modification

12.3(1)

This feature was introduced.

Supported Platforms

Cisco AS5300, Cisco AS5350, Cisco AS5400, Cisco AS5800, Cisco AS5850, Cisco 2600 series, Cisco 3640, Cisco 3660

Finding Support Information for Platforms and Cisco IOS Software Images

at the login dialog box and follow the instructions that appear.

Contents

- Prerequisites for ISDN BCAC Enhancements

- Information About the ISDN BCAC and Round-Robin Channel Selection Enhancements

- How to Configure the ISDN Enhancements

- Configuration Examples for ISDN BCAC and Round-Robin Channel Selection Enhancements

- Additional References

- Command Reference

Prerequisites for ISDN BCAC Enhancements

You need to need to be familiar with the BCAC service message signaling procedure and configuring ISDN PRI before configuring the commands described in this document. See the “Standards” section for a list of references.

Information About the ISDN BCAC and Round-Robin Channel Selection Enhancements

The following functionality is introduced in the ISDN BCAC and Round-Robin Channel Selection Enhancements:

- BCAC Enhancements

- Round-Robin Selection Scheme for ISDN B Channels

- Logging of ISDN Events

- Additional ISDN Switch Types Supported for Network Emulation

BCAC Enhancements

BCAC is a service message signaling procedure used to control the availability of ISDN B channels. BCAC provides a coordinated capability between both ends of a PRI to simultaneously preclude selection of specified B channels for outgoing calls, and reject calls (if channel negotiation is employed, calls may go on another channel) for those same channels. The basic BCAC functionality for the handling of SERV and SERV ACK messages already exists on Cisco routers. In Cisco IOS Release 12.3(1), the software has been enhanced with the following BCAC functionality:

- Processing of SERV and SERV ACK messages. Even though these messages are already handled in the Cisco IOS software, their processing has been enhanced to more closely align with the behavior described in the standards.

- Provides a mechanism to allow the retransmission of SERV messages.

- Handles SERV message collision cases.

- Provides service status audits for various audit triggers.

- Provides an option that when set triggers the exchange of service messages on all channels of the interface when the router is rebooted and when the signaling link comes up.

- Provides a mechanism so that if there is a flood of service messages that need to be sent, the service messages can be throttled to avoid losing them.

- Initializes B-channel service status upon provisioning.

Round-Robin Selection Scheme for ISDN B Channels

ISDN enhancements introduced in Cisco IOS Release 12.3(1) enable you to select a B channel on a PRI or a Non-Facility Associated Signaling (NFAS) interface in a round-robin fashion. This option is in addition to the ascending or descending channel selection schemes already available.

Logging of ISDN Events

ISDN enhancements introduced in Cisco IOS Release 12.3(1) support syslog logging of the following ISDN events:

- ISDN Layer 2 Up and Down events at severity 3.

- ISDN SERV, SERV ACK, Restart, Restart Ack, and Status Enq messages at severity 4.

- ISDN SERV status audit messages for various triggers at different severities.

Additional ISDN Switch Types Supported for Network Emulation

ISDN enhancements introduced in Cisco IOS Release 12.3(1) extend network emulation capability to the Lucent 4ESS, 5ESS, and Nortel DMS-100 ISDN switch types. These switch types can be configured as network, but no additional changes were made and not all network-side features are supported.

How to Configure the ISDN Enhancements

This section contains the following procedures. Each procedure is optional and depends upon the settings required for your network.

- Configuring BCAC Service Audit Triggers (optional)

- Configuring BCAC Service State Triggers (optional)

- Configuring BCAC Message Retransmission (optional)

- Configuring B-Channel Selection Order (optional)

- Configuring ISDN Syslog Messages (optional)

Configuring BCAC Service Audit Triggers

Perform this task to configure BCAC service audit triggers:

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# interface serial 2:23

Enters interface configuration mode on the specified serial port and channel.

Step 4

Router(config-if)# isdn bcac service audit

Enables BCAC service audits.

Step 5

Router(config-if)# isdn bcac service audit trigger 2

Enables individual BCAC service audit triggers.

Step 6

Specifies that BCAC service audits need to be triggered on the entire interface.

Examples

The following example shows how to enable service audits on serial interface 4:23:

interface serial 4:23

isdn bcac service audit

The following example shows how to disable service trigger 4 on serial interface 4:23:

interface serial 4:23

no isdn bcac service audit trigger 4

command for a list of the triggers that are set.

The following example shows how to configure service audits on the entire interface:

interface serial 4:23

isdn bcac service audit interface

Configuring BCAC Service State Triggers

Perform this task to configure BCAC service state triggers:

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# interface serial 2:23

Enters interface configuration mode on the specified serial port and channel.

Step 4

Router(config-if)# isdn bcac service update provision

Enables BCAC service status functionality for provisioning the B channels.

Step 5

Triggers updates of the BCAC service states between peer nodes through exchange of SERV and SERV ACK messages.

Examples

The following example shows how to enable the SERV status message for provisioning the B channels on serial interface 4:23:

interface serial 4:23

isdn bcac service update provision

The following example shows how to trigger service state updates on serial interface 4:23:

interface serial 4:23

isdn bcac service update linkup

Configuring BCAC Message Retransmission

Perform this task to configure retransmission of BCAC service messages:

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# interface serial 2:23

Enters interface configuration mode on the specified serial port and channel.

Step 4

Router(config-if)# isdn bcac service timer 600

Changes the value of the BCAC T3M1 or T323 service message timer.

- Valid range is from 500 to 120000 ms, and the default is 120000 ms.

Step 5

Router(config-if)# isdn bcac service retry max retries

Specifies the maximum number of times a BCAC service message can be retransmitted when unacknowledged.

- The default is 2 attempts, and you can enter a number from 0 to 127.

Step 6

isdn bcac service retry in-serv-on-fail

Specifies that the BCAC service state of the channel needs to be changed to In-Service, because no acknowledgment message was received.

Examples

The following example shows how to configure an option whereby, on service message exchange failure, the service state of the concerned channel or channels will be set to In-Service:

interface serial 2:23

isdn bcac service retry in-serv-on-fail

The following example shows how to set the maximum number of service message retransmissions on serial interface 2:23 to 50:

interface serial 2:23

isdn bcac service retry max 50

The following example shows how to change the service timers to 600 ms on serial interface 2:23:

interface serial 2:23

isdn bcac service timer 600

Configuring B-Channel Selection Order

Perform this task to configure selection order of the ISDN B channels:

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# interface serial 2:23

Enters interface configuration mode on the specified serial port and channel.

Step 4

]

Router(config-if)# isdn bchan-number-order ascending round-robin

Configures an ISDN PRI interface to make outgoing call selection in ascending or descending order.

- The optional round-robin keyword adds round-robin selection functionality to the selection order.

Examples

The following example configures the outgoing B channel selection order on a PRI interface to be round-robin in ascending order:

interface serial 5:10

isdn bchan-number-order ascending round-robin

Configuring ISDN Syslog Messages

Perform this task to configure logging of ISDN syslog messages:

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# isdn logging

Enables logging of ISDN syslog messages.

Examples

The following example shows how to configure ISDN syslog logging:

isdn logging

Configuration Examples for ISDN BCAC and Round-Robin Channel Selection Enhancements

See the examples following each task in the preceding sections, for ideas about how the ISDN CBAC enhancements and other new ISDN features can be introduced into your network.

Additional References

For additional information related to the ISDN enhancements, see the following sections:

- Related Documents

- Standards

- MIBs

- RFCs

- Technical Assistance

Related Documents

Related Topic

Document Title

ISDN PRI configuration

, Release 12.3.

ISDN PRI configuration commands

, Release 12.3.

ISDN PRI configuration for voice, video, and fax

, Release 12.3.

ISDN PRI voice, video, and fax configuration commands

, Release 12.3

Standards

Standards 1

Title

AT&T PRI

; “User Network Interface Description,” 1999.

National ISDN Council (NIC) PRI

, June 1993.

, 1996.

Nortel PRI

.

1.Not all supported standards are listed.

1.Not all supported standards are listed.

MIBs

MIBs

MIBs Link

None

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

RFCs

RFCs

Title

None

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

Command Reference

.

- isdn bcac service audit

- isdn bcac service audit interface

- isdn bcac service audit trigger

- isdn bcac service retry in-serv-on-fail

- isdn bcac service retry max

- isdn bcac service timer

- isdn bcac service update linkup

- isdn bcac service update provision

- isdn logging

- isdn bchan-number-order

- isdn protocol-emulate (dial)

Glossary

—private branch exchange.

—restart message.

—restart acknowledge message.

—status enquiry message.

—service message.

—service acknowledge message.

Note Refer to the Internetworking Terms and Acronyms for terms not included in this glossary.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001–2009 Cisco Systems, Inc. All rights reserved

Configuring Virtual Asynchronous Traffic

over ISDN

Cisco IOS software offers two solutions to send virtual asynchronous traffic over ISDN:

- Using International Telecommunication Union Telecommunication Standardization Sector (ITU-T) Recommendation V.120, which allows for reliable transport of synchronous, asynchronous, or bit transparent data over ISDN bearer channels.

- Using ITU-T Recommendation X.75, which allows a system with an ISDN terminal adapter supporting asynchronous traffic over Link Access Procedure, Balanced (LAPB) to call into a router and establish an asynchronous PPP session. This method of asynchronous traffic transmission is also called ISDN Link Access Procedure, Balanced-Terminal Adapter (LAPB-TA).

A virtual asynchronous interface (also known as vty-async) is created on demand to support calls that enter the router through a nonphysical interface. For example, asynchronous character stream calls terminate or land on nonphysical interfaces. These types of calls include inbound Telnet, local-area transport (LAT), PPP over character-oriented protocols (such as V.120 or X.25), and LAPB-TA and packet assembler/disassembler (PAD) calls.

, for additional virtual asynchronous interface configuration information.

This chapter describes how to configure virtual asynchronous traffic over ISDN lines. It includes the following main sections:

- Recommendation V.120 Overview

- How to Configure V.120 Access

- Configuration Example for V.120

- ISDN LAPB-TA Overview

- How to Configure ISDN LAPB-TA

- Configuration Example for ISDN LAPB-TA

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

Recommendation V.120 Overview

The V-series recommendations are ITU-T standards dealing with data communications over telephone networks. V.120 allows for reliable transport of synchronous, asynchronous, or bit transparent data over ISDN bearer channels. Cisco provides three V.120 support features for terminal adapters that do not send the low-layer compatibility fields or bearer capability V.120 information:

- Answer all incoming calls as V.120—Static configuration used when all remote users have asynchronous terminals and need to connect with a vty on the router.

- Automatically detect V.120 encapsulation—Encapsulation dynamically detected and set.

- Enable V.120 Support for Asynchronous Access over ISDN.

For terminal adapters that send the low-layer compatibility or bearer capability V.120 information, mixed V.120 and ISDN calls are supported. No special configuration is required.

How to Configure V.120 Access

To configure V.120 access, perform the tasks in the following sections:

- Configuring Answering of All Incoming Calls as V.120 (Required)

- Configuring Automatic Detection of Encapsulation Type (Required)

- Enabling V.120 Support for Asynchronous Access over ISDN (Required)

See the section “Configuration Example for V.120” at the end of this chapter for an example of how to configure V.120 access.

Configuring Answering of All Incoming Calls as V.120

This V.120 support feature allows users to connect using an asynchronous terminal over ISDN terminal adapters with V.120 support to a vty on the router, much like a direct asynchronous connection. Beginning with Cisco IOS Release 11.1, this feature supports incoming calls only.

When all the remote users have asynchronous terminals and call in to a router through an ISDN terminal adapter that uses V.120 encapsulation but does not send the low-layer compatibility or bearer capability V.120 information, you can configure the interface to answer all calls as V.120. Such calls are connected with an available vty on the router.

To configure an ISDN BRI or PRI interface to answer all incoming calls as V.120, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Cisco 4000 series routers only

or

Cisco 7200 series routers only

Router(config)# interface bri slot / port

Configures the ISDN BRI interface and begins interface configuration mode.

Step 2

or

Configures the ISDN PRI D channel and begins interface configuration mode.

Step 3

Configures the interface to answer all calls as V.120.

Configuring Automatic Detection of Encapsulation Type

If an ISDN call does not identify the call type in the lower-layer compatibility fields and is using an encapsulation that is different from the one configured on the interface, the interface can change its encapsulation type dynamically.

This feature enables interoperation with ISDN terminal adapters that use V.120 encapsulation but do not signal V.120 in the call setup message. An ISDN interface that by default answers a call as synchronous serial with PPP encapsulation can change its encapsulation and answer such calls.

Automatic detection is attempted for the first 10 seconds after the link is established or the first 5 packets exchanged over the link, whichever is first.

To enable automatic detection of V.120 encapsulation, use the following command in interface configuration mode:

Command

Purpose

Enables automatic detection of encapsulation type on the specified interface.

You can specify one or more encapsulations to detect. Cisco IOS software currently supports automatic detection of PPP and V.120 encapsulations.

Enabling V.120 Support for Asynchronous Access over ISDN

You can optionally configure a router to support asynchronous access over ISDN by globally enabling PPP on vty lines. Asynchronous access is then supported over ISDN from the ISDN terminal to the vty session on the router.

To enable asynchronous protocol features on vty lines, use the following command in global configuration mode:

Command

Purpose

Configures all vty lines to support asynchronous protocol features.

.

Configuration Example for V.120

The following example configures BRI 0 to call and receive calls from two sites, to use PPP encapsulation on outgoing calls, and to use Challenge Handshake Authentication Protocol (CHAP) authentication on incoming calls. This example also enables BRI 0 to configure itself dynamically to answer calls that use V.120 but that do not signal V.120 in the call setup message.

interface bri 0

encapsulation ppp

autodetect encapsulation v120

no keepalive

dialer map ip 172.18.36.10 name EB1 234

dialer map ip 172.18 36.9 name EB2 456

dialer-group 1

ppp authentication chap

ISDN LAPB-TA Overview

To carry asynchronous traffic over ISDN, your system must be able to convert that traffic and forward it over synchronous connections. This process can be implemented by the V.120 protocol, which carries asynchronous traffic over ISDN. However, several countries in Europe (Germany, Switzerland, and some Eastern European countries) use LAPB as the protocol to forward their asynchronous traffic over synchronous connections. Your system, therefore, must be able to recognize and accept calls from these asynchronous/synchronous conversion devices. LAPB-TA performs that function. (LAPB is sometimes referred to as “X.75,” because LAPB is the link layer specified in the ITU-T X.75 recommendation for carrying asynchronous traffic over ISDN.)

LAPB-TA allows devices that use LAPB instead of the V.120 protocol to communicate with routers on the Cisco 3600 and 5300 series.

LAPB supports both local CHAP authentication and external RADIUS authorization on the authentication, authorization, and accounting (AAA) server.

Before configuring ISDN LAPB-TA in your network, observe these restrictions:

- LAPB-TA does not currently support the ability to set a maximum frame size per user.

- Outbound LAPB-TA calls are not supported.

- PPP over LAPB-TA (and V.120) connections impose a greater overhead on the router than synchronous PPP over ISDN. The number of simultaneous sessions can be limited by dedicating a pool of virtual terminals to these protocols and limiting the number of virtual terminals in the pool.

- Multilink PPP compression is not supported.

How to Configure ISDN LAPB-TA

ISDN LAPB-TA is supported on the Cisco 3600 and Cisco 5300 series routers that meet the following additional requirements:

- A virtual terminal must be configured for incoming LAPB-TA. If no appropriately configured virtual terminals are available, the incoming call will be cleared.

- ISDN, LAPB, and PPP must be running to configure LAPB-TA.

- The Cisco IOS software must include the vty-async global configuration command, which must be configured before you can run asynchronous PPP traffic over a LAPB-TA connection.

If an interface is already configured for V.120, only the following two additional configuration commands are required on the interface because V.120 and LAPB-TA sessions are configured in a similar way:

- Use the autodetect encapsulation command to enable autodetection of LAPB-TA connections.

- Use the transport input command to list LAPB-TA as an acceptable transport on a specific router.

Perform the following required task to configure LAPB-TA: To configure ISDN LAPB-TA, use the following commands beginning in global configuration command mode: (required).

Procedures for verifying the configuration are found in the section “Verifying ISDN LAPB-TA” later in this chapter. The section “Configuration Example for ISDN LAPB-TA” at the end of this chapter provides configuration examples.

To configure ISDN LAPB-TA, use the following commands beginning in global configuration command mode:

Command

Purpose

Step 1

Creates a virtual asynchronous interface.

Step 2

Applies virtual template to the virtual asynchronous interface.

Step 3

Creates a virtual interface template and enters interface configuration mode.

Step 4

Assigns an IP address to the virtual interface template.

Step 5

Enables encapsulation on the virtual interface template.

Step 6

Disables an IP address from a pool to the device connecting to the virtual access interface

Step 7

Enables the CHAP protocol for PPP authentication.

Step 8

Exits to global configuration mode.

Step 9

Specifies CHAP password to be used to authenticate calls from caller “user1.”

Step 10

Enters interface configuration mode for a D-channel serial interface.1

Step 11

Configures PPP encapsulation as the default.

Step 12

Specifies the dialer group belonging to the interface.

Step 13

Enables the CHAP protocol for PPP authentication.

Step 14

Enables autodetect encapsulation for LAPB-TA protocols.

Step 15

Configures a range of 32 vty lines starting with vty0.

Step 16

Defines which protocol to use to connect to a specific line of the access server.

1.The D channel is the signaling channel.

1.The D channel is the signaling channel.

Verifying ISDN LAPB-TA

command to verify that LAPB-TA is configured. The following output shows LAPB-TA enabled for serial interface 0:23:

Router# show running configuration

Building configuration...

Current configuration:

!

version 12.0

service timestamps debug datetime msec localtime

service timestamps log datetime msec localtime

no service password-encryption

service udp-small-servers

service tcp-small-servers

!

hostname Router

...(output omitted)

interface Serial0:23

description ENG PBX BRI num.:81063

no ip address

no ip directed-broadcast

encapsulation ppp

no ip route-cache

dialer pool-member 1

autodetect encapsulation ppp lapb-ta

isdn switch-type primary-5ess

no peer default ip address

no fair-queue

no cdp enable

ppp authentication chap

...(output omitted)

!

end

Configuration Example for ISDN LAPB-TA

The following example configures a virtual template LAPB-TA connection capable of running PPP. It assumes that you have already configured usernames and passwords for PPP authentication.

vty-async

vty-async virtual-template 1

interface virtual-template 1

ip unnumbered Ethernet0

encapsulation ppp

no peer default ip address

ppp authentication chap

exit

interface Serial0:23

autodetect encapsulation lapb-ta

The following example treats the LAPB-TA and V.120 calls identically by immediately starting a PPP session without asking for username and password and relying on PPP authentication to identify the caller:

vty-async

vty-async virtual-template 1

interface Loopback0

ip address 10.2.2.1 255.255.255.0

exit

interface BRI3/0

encapsulation ppp

autodetect encapsulation ppp lapb-ta v120

exit

interface Virtual-Template1

ip unnumbered Loopback0

ppp authentication chap

exit

ip local pool default 10.2.2.64 10.2.2.127

line vty 0 2

password <removed>

login

transport input telnet

exit

line vty 3 4

no login

transport input lapb-ta v120

autocommand ppp neg

exit

end

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001–2009 Cisco Systems, Inc. All rights reserved.

Configuring Modem Use over ISDN BRI

This chapter describes how to configure the Modem over ISDN BRI feature. It includes the following main sections:

- Modem over ISDN BRI Overview

- How to Configure Modem over ISDN BRI

- Verifying ISDN BRI Interface Configuration

- Configuration Examples for Modem over ISDN BRI

Before beginning the tasks in this chapter, check your system for the following hardware and software:

- At least one of the following digital modem network modules. The number in the model name indicates the number of digital modems that can be connected to the module.

– NM-6DM

– NM-12DM

– NM-18DM

– NM-24DM

– NM-30DM

support BRI voice interface cards or wide-area network (WAN) interface cards.

- At least one of the following Cisco BRI network modules:

– NM-4B-S/T: 4-port ISDN BRI network module, minimum version 800-01236-03

– NM-4B-U: 4-port ISDN BRI with integrated network termination 1 (NT-1) network module, minimum version 800-01238-06

– NM-8B-S/T: 8-port ISDN BRI network module, minimum version 800-01237-03

– NM-8B-U: 8-port ISDN BRI with integrated NT-1 network module, minimum version 800-01239-06

The version level is available from the show diag command, which displays the version number as the part number.

in the Access Products index. If your existing Cisco BRI network module is one of those listed and does not support the Modem over ISDN BRI feature, Cisco will upgrade the module at no charge.

- To support the Modem over ISDN BRI feature, V.90 modem portware—for instructions on downloading this software or obtaining it otherwise, refer to the Cisco 3600 Series Modem Portware Upgrade Configuration Note on Cisco.com.

Before you can configure a Cisco 3640 router to provide Modem over ISDN BRI connectivity, you must also perform the following tasks:

- Obtain BRI service from your telecommunications provider. The BRI line must be provisioned at the switch to support voice calls.

- Install a 4-port or 8-port BRI network module into your Cisco router. Depending on the type of network module and your BRI service, you might also need to install an external NT-1 for S/T interfaces.

- Install a supported digital modem network module into the Cisco 3640 router.

- After the system comes up, make sure enough buffers are in the free list of the buffer pool that matches the maximum transmission unit (MTU) of your BRI interface. If not, you must reconfigure buffers so the BRI interfaces function properly. To check the MTU of your interfaces, use the show interfaces bri command. The show buffers command displays the free buffer space. Use the buffers global configuration command to make adjustments to initial buffer pool settings and to the limits at which temporary buffers are created and destroyed.

that came with your BRI network module or view the up-to-date information on CCO.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

Modem over ISDN BRI Overview

The Modem over ISDN BRI feature for the Cisco 3640 modular access router lowers the cost of remote access by offering high-speed modem and ISDN connectivity for mobile customers, offices, and other remote-access users. Branch offices and enterprises can support analog modem users who call over the Public Switched Telephone Network (PSTN) into BRI interfaces in Cisco 3640 routers.

The digital modem in the router accepts the modem calls at connection speeds as fast as 56 kbps, adhering to the V.90 standard. As shown in Figure 1, the Cisco 3640 router in this way provides rapid access to E-mail and other network services.

Figure 1 Modem over ISDN BRI Feature

The following are benefits of using the Modem over ISDN BRI feature:

- Supports cost-effective and readily available BRI service.

- Provides remote modem users with rapid Internet and LAN/WAN access.

- Allows flexible remote access application support.

How to Configure Modem over ISDN BRI

The Modem over ISDN BRI feature is part of interface configuration for BRI. You configure the BRI interface after you have configured the ISDN global characteristics, which are switch type and TEI negotiation timing. These characteristics can also be defined for each BRI interface, as shown in the following task table.

To set up the BRI interface characteristics, set the global parameters and then configure each interface separately by using the following commands beginning in global configuration mode:

Command

Purpose

Step 1

.

Step 2

]

Configures when the ISDN TEI negotiation occurs. If this command is not used, negotiation occurs when the router is powered up.

option should be used in most other locations.

Step 3

Begins interface configuration mode to configure parameters for the specified interface.

is the location of the BRI module. Valid values are from 0 to 3.

is an interface number. Valid values are from 0 to 7 if the module is an 8-port BRI network module, or from 0 to 4 if the module is a 4-port BRI network module.

Step 4

publication.

Step 5

Enables PPP encapsulation on the BRI interface. PPP encapsulation is configured for most ISDN communication.

If the router needs to communicate with devices that require a different encapsulation protocol, needs to detect encapsulation on incoming calls automatically, or needs to send traffic over a Frame Relay or X.25 network, see the chapter “Configuring X.25 on ISDN” later in this part, and the chapters in the Dial-on-Demand Routing Configuration part of this publication for information.

Step 6

or

(Most locations) Defines the remote protocol address of the recipient, host name, and dialing string; optionally, provide the ISDN subaddress; set the dialer speed to 56 or 64 kbps, as needed.

keyword to enable ISDN semipermanent connections.

Step 7

Assigns the interface to a dialer group to control access to the interface.

Step 8

Associates the dialer group number with an access list number.

Step 9

Defines an access list permitting or denying access to specified protocols, sources, or destinations. Permitted packets cause the router to place a call to the destination protocol address.

Step 10

(Optional) Disables the translation of directed broadcast to physical broadcasts.

Step 11

(Optional) Configures the interface ISDN switch type to match the service provider switch type. The interface ISDN switch type overrides the global ISDN switch type on the interface.

.

Step 12

]

(Optional) Determines when ISDN TEI negotiation occurs for an individual interface. This overrides the global configuration command.

Step 13

]

Specifies a service profile identifier (SPID) and local directory number for the B1 channel. Currently, only the DMS-100 and NI-1 switch types require SPIDs. Although the Lucent 5ESS switch type might support a SPID, we recommend that you set up that ISDN service without SPIDs.

Step 14

]

Specifies a SPID and local directory number for the B2 channel.

Step 15

(Optional) Configure caller ID screening.

Step 16

]

(Optional) Configures called-party number verification for a called-party number or subaddress number in the incoming setup message.

Step 17

(Optional) Specifies the calling-party number.

Step 18

]

(Optional) Configures the speed for incoming calls recognized as not ISDN end-to-end.

Step 19

Routes incoming voice calls to the modem and treats them as analog data. This step is required for the Modem over ISDN BRI feature.

Step 20

| busy | not available}

Overrides specific cause codes such as modem availability and resource pooling that are sent to the switch by ISDN applications. When the isdn disconnect-cause command is implemented, the configured cause codes are sent to the switch; otherwise, the default cause codes of the application are sent.

argument sends a cause code number (submitted as integer 1 through 127) to the switch.

The busy keyword sends the USER BUSY code to the switch.

The not available keyword sends the CHANNEL NOT AVAILABLE code to the switch.

Step 21

(Optional) Configures a delay between fast rollover dials.

Step 22

(Optional) Configures the BRI interface to include the Sending Complete information element in the outgoing call Setup message. Used in some geographic locations, such as Hong Kong and Taiwan, where the sending complete information element is required in the outgoing call setup message.

Table 1 ISDN Switch Types

Country

ISDN Switch Type

Description

Australia

Australian TS013 switches

Europe

German 1TR6 ISDN switches

NET3 ISDN switches (United Kingdom and others)

French VN2 ISDN switches

French VN3 and VN4 ISDN switches

Japan

Japanese NTT ISDN switches

North America

Lucent Technologies basic rate switches

NT DMS-100 basic rate switches

National ISDN-1 switches

See the section “Configuration Examples for Modem over ISDN BRI” at the end of this chapter for configuration examples.

Verifying ISDN BRI Interface Configuration

command in EXEC mode to verify the current configuration that is running on the terminal.

Note The show startup-config shows the configuration stored in NVRAM or in a location specified by the CONFIG_FILE environment variable.

Building configuration...

Current configuration:

!

version 12.0

no service udp-small-servers

service tcp-small-servers

!

hostname Router

!

enable secret 5 $1$c8xi$tObplXsIS.jDeo43yZgq50

enable password xxx

!

username xxxx password x 11x5xx07

no ip domain-lookup

ip host Labhost 172.17.12.1

ip host Labhost2 172.17.12.2

ip name-server 172.19.169.21

!

interface Ethernet0

ip address 172.17.12.100 255.255.255.192

no ip mroute-cache

no ip route-cache

no mop enabled

.

.

.

interface BRI1/7

description (408) 555-3777

ip address 10.1.1.26 255.255.255.1

no ip directed-broadcast

encapsulation ppp

no ip route-cache

no ip mroute-cache

no keepalive

shutdown

dialer idle-timeout 180

dialer map ip 10.1.1.9 name MDial1 14085550715

dialer map ip 10.1.1.14 name MDial2 14085553775

dialer-group 1

isdn switch-type basic-5ess

isdn incoming-voice modem

isdn disconnect-cause busy

no fair-queue

no cdp enable

ppp authentication chap

ppp multilink

.

.

.

!

interface Group-Async1

ip unnumbered Loopback0

no ip directed-broadcast

ip tcp header-compression passive

async mode interactive

peer default ip address pool default

no fair-queue

group-range 65 70

hold-queue 10 in

!

router igrp 109

network 172.21.0.0

!

ip local pool local 172.21.50.85 172.21.50.89

ip local pool default 10.1.1.1 10.1.1.253

ip classless

ip route 0.0.0.0 0.0.0.0 172.21.48.1

!

!

map-class dialer VOICE

dialer voice-call

!

map-class dialer DATA

dialer-list 1 protocol ip list 101

tacacs-server host 172.19.2.74

tacacs-server host 192.168.15.197

snmp-server community isdn RW

snmp-server enable traps isdn call-information

snmp-server host 172.25.3.154 traps isdn

argument is the slot location of the BRI module. Valid values are from 0 to 3.

BRI0:1 is down, line protocol is down

Hardware is BRI

MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255

Internet address is 10.1.1.3/27

Encapsulation PPP, loopback not set, keepalive not set

LCP Closed

Closed: IPCP

Last input never, output never, output hang never

Last clearing of "show interface" counters never

Queueing strategy: fifo

Output queue 0/40, 0 drops; input queue 0/75, 0 drops

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

0 packets input, 0 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

0 packets output, 0 bytes, 0 underruns

0 output errors, 0 collisions, 7 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

Configuration Examples for Modem over ISDN BRI

This section provides the following examples:

- BRI Interface Configuration Example

- Complete Configuration Examples

These examples show configuration of just the Modem over ISDN BRI feature using the interface configuration commands for each interface and a complete configuration showing global configuration, BRI interfaces, and modem configuration.

BRI Interface Configuration Example

The following example shows how to configure each BRI interface on a Cisco 3640 router for the Modem over ISDN BRI feature:

interface BRI0/0

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0444000101 9194440001

isdn spid2 0444001101 9194440011

isdn incoming-voice modem

!

interface BRI0/1

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0444000201 9194440002

isdn spid2 0444001201 9194440012

isdn incoming-voice modem

!

interface BRI0/2

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0444000301 9194440003

isdn spid2 0444001301 9194440013

isdn incoming-voice modem

!

interface BRI0/3

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0444000401 9194440004

isdn spid2 0444001401 9194440014

isdn incoming-voice modem

!

interface BRI0/4

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0444000501 9194440005

isdn spid2 0444001501 9194440015

isdn incoming-voice modem

!

interface BRI0/5

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0444000601 9194440006

isdn spid2 0444001601 9194440016

isdn incoming-voice modem

!

interface BRI0/6

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0444000701 9194440007

isdn spid2 0444001701 9194440017

isdn incoming-voice modem

!

interface BRI0/7

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0444000801 9194440008

isdn spid2 0444001801 9194440018

isdn incoming-voice modem

!

interface BRI2/0

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0555000101 9195550001

isdn spid2 0555001101 9195550011

isdn incoming-voice modem

!

interface BRI2/1

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0555000201 9195550002

isdn spid2 0555001201 9195550012

isdn incoming-voice modem

!

interface BRI2/2

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0555000301 9195550003

isdn spid2 0555001301 9195550013

isdn incoming-voice modem

!

interface BRI2/3

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0555000401 9195550004

isdn spid2 0555001401 9195550014

isdn incoming-voice modem

!

interface BRI2/4

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0555000501 9195550005

isdn spid2 0555001501 9195550015

isdn incoming-voice modem

!

interface BRI2/5

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0555000601 9195550006

isdn spid2 0555001601 9195550016

isdn incoming-voice modem

!

interface BRI2/6

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0555000701 9195550007

isdn spid2 0555001701 9195550017

isdn incoming-voice modem

!

interface BRI2/7

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0555000801 9195550008

isdn spid2 0555001801 9195550018

isdn incoming-voice modem

!

Complete Configuration Examples

commands.

version 12.0

service timestamps debug datetime localtime

service timestamps log uptime

no service password-encryption

service udp-small-servers

service tcp-small-servers

!

hostname MBRI_IN

!

no logging buffered

enable password xxx

The following lines are used for PPP CHAP authentication. Each username and password is associated with one dialer interface.

username async1 password devtest

username async2 password devtest

username async3 password devtest

username async4 password devtest

username async5 password devtest

username async6 password devtest

username async7 password devtest

username async8 password devtest

username async9 password devtest

username async10 password devtest

username async11 password devtest

username async12 password devtest

username async13 password devtest

username async14 password devtest

username async15 password devtest

username async16 password devtest

username async17 password devtest

username async18 password devtest

username async19 password devtest

username async20 password devtest

username async21 password devtest

username async22 password devtest

username async23 password devtest

username async24 password devtest

username async25 password devtest

username async26 password devtest

username async27 password devtest

username async28 password devtest

username async29 password devtest

username async30 password devtest

username FLOYD password devtest

username MBRI_OUT password devtest

ip subnet-zero

no ip domain-lookup

!

isdn switch-type basic-5ess

interface BRI0/0

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0444000101 9194440001

isdn spid2 0444001101 9194440011

isdn incoming-voice modem

!

interface BRI0/1

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0444000201 9194440002

isdn spid2 0444001201 9194440012

isdn incoming-voice modem

!

interface BRI0/2

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0444000301 9194440003

isdn spid2 0444001301 9194440013

isdn incoming-voice modem

!

interface BRI0/3

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0444000401 9194440004

isdn spid2 0444001401 9194440014

isdn incoming-voice modem

!

interface BRI0/4

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0444000501 9194440005

isdn spid2 0444001501 9194440015

isdn incoming-voice modem

no shut

!

interface BRI0/5

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0444000601 9194440006

isdn spid2 0444001601 9194440016

isdn incoming-voice modem

!

interface BRI0/6

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0444000701 9194440007

isdn spid2 0444001701 9194440017

isdn incoming-voice modem

!

interface BRI0/7

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0444000801 9194440008

isdn spid2 0444001801 9194440018

isdn incoming-voice modem

!

interface BRI2/0

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0555000101 9195550001

isdn spid2 0555001101 9195550011

isdn incoming-voice modem

!

interface BRI2/1

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0555000201 9195550002

isdn spid2 0555001201 9195550012

isdn incoming-voice modem

!

interface BRI2/2

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0555000301 9195550003

isdn spid2 0555001301 9195550013

isdn incoming-voice modem

!

interface BRI2/3

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0555000401 9195550004

isdn spid2 0555001401 9195550014

isdn incoming-voice modem

!

interface BRI2/4

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0555000501 9195550005

isdn spid2 0555001501 9195550015

isdn incoming-voice modem

!

interface BRI2/5

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0555000601 9195550006

isdn spid2 0555001601 9195550016

isdn incoming-voice modem

!

interface BRI2/6

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0555000701 9195550007

isdn spid2 0555001701 9195550017

isdn incoming-voice modem

!

interface BRI2/7

no ip address

no ip directed-broadcast

encapsulation ppp

isdn switch-type basic-ni

isdn spid1 0555000801 9195550008

isdn spid2 0555001801 9195550018

isdn incoming-voice modem

!

interface Ethernet1/0

ip address 172.18.16.123 255.255.255.192

no ip directed-broadcast

!

The following example defines a group-async interface for grouping all the digital modems and configuring them together. Group-async configuration is much easier than configuring all 30 digital modems individually.

interface Group-Async1

ip unnumbered Ethernet3/1

no ip directed-broadcast

encapsulation ppp

load-interval 30

dialer in-band

dialer pool-member 1

async default routing

async mode dedicated

no peer default ip address

no cdp enable

ppp authentication chap

group-range 96 125

hold-queue 10 in

The following example defines dialer interfaces, associates IP addresses, and sets all the authentication parameters required during the call establishment.

interface Dialer1

ip address 10.1.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async1

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async1

ppp chap password devtest

!

interface Dialer2

ip address 10.2.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async2

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async2

ppp chap password devtest

!

interface Dialer3

ip address 10.3.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async3

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async3

ppp chap password devtest

!

interface Dialer4

ip address 10.4.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async4

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async4

ppp chap password devtest

!

interface Dialer5

ip address 10.5.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async5

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async5

ppp chap password devtest

!

interface Dialer6

ip address 10.6.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async6

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async6

ppp chap password devtest

!

interface Dialer7

ip address 10.7.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async7

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async7

ppp chap password devtest

!

interface Dialer8

ip address 10.8.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async8

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async8

ppp chap password devtest

!

interface Dialer9

ip address 10.9.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async9

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async9

ppp chap password devtest

!

interface Dialer10

ip address 10.10.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async10

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async10

ppp chap password devtest

!

interface Dialer11

ip address 10.11.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async11

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async11

ppp chap password devtest

!

interface Dialer12

ip address 10.12.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async12

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async12

ppp chap password devtest

!

interface Dialer13

ip address 10.13.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async13

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async13

ppp chap password devtest

!

interface Dialer14

ip address 10.14.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async14

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async14

ppp chap password devtest

!

interface Dialer15

ip address 10.15.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async15

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async15

ppp chap password devtest

!

interface Dialer16

ip address 10.16.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async16

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async16

ppp chap password devtest

!

interface Dialer17

ip address 10.17.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async17

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async17

ppp chap password devtest

!

interface Dialer18

ip address 10.18.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async18

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async18

ppp chap password devtest

!

interface Dialer19

ip address 10.19.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async19

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async19

ppp chap password devtest

!

interface Dialer20

ip address 10.20.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async20

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async20

ppp chap password devtest

!

interface Dialer21

ip address 10.21.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async21

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async21

ppp chap password devtest

!

interface Dialer22

ip address 10.22.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async22

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async22

ppp chap password devtest

!

interface Dialer23

ip address 10.23.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async23

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async23

ppp chap password devtest

!

interface Dialer24

ip address 10.24.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async24

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async24

ppp chap password devtest

!

interface Dialer25

ip address 10.25.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async25

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async25

ppp chap password devtest

!

interface Dialer26

ip address 10.26.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async26

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async26

ppp chap password devtest

!

interface Dialer27

ip address 10.27.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async27

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async27

ppp chap password devtest

!

interface Dialer28

ip address 10.28.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async28

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async28

ppp chap password devtest

!

interface Dialer29

ip address 10.29.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async29

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async29

ppp chap password devtest

!

interface Dialer30

ip address 10.30.0.1 255.255.0.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name async30

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap callin

ppp chap hostname async30

ppp chap password devtest

!

no ip classless

The following lines define routes that send incoming packets out via specific interfaces:

ip route 0.0.0.0 0.0.0.0 172.18.16.193

ip route 10.91.0.1 255.255.255.255 1.1.0.2

ip route 10.91.0.2 255.255.255.255 1.2.0.2

ip route 10.91.0.3 255.255.255.255 1.3.0.2

ip route 10.91.0.4 255.255.255.255 1.4.0.2

ip route 10.91.0.5 255.255.255.255 1.5.0.2

ip route 10.91.0.6 255.255.255.255 1.6.0.2

ip route 10.91.0.7 255.255.255.255 1.7.0.2

ip route 10.91.0.8 255.255.255.255 1.8.0.2

ip route 10.91.0.9 255.255.255.255 1.9.0.2

ip route 10.91.0.10 255.255.255.255 1.10.0.2

ip route 10.91.0.11 255.255.255.255 1.11.0.2

ip route 10.91.0.12 255.255.255.255 1.12.0.2

ip route 10.91.0.13 255.255.255.255 1.13.0.2

ip route 10.91.0.14 255.255.255.255 1.14.0.2

ip route 10.91.0.15 255.255.255.255 1.15.0.2

ip route 10.91.0.16 255.255.255.255 1.16.0.2

ip route 10.91.0.17 255.255.255.255 1.17.0.2

ip route 10.91.0.18 255.255.255.255 1.18.0.2

ip route 10.91.0.19 255.255.255.255 1.19.0.2

ip route 10.91.0.20 255.255.255.255 1.20.0.2

ip route 10.91.0.21 255.255.255.255 1.21.0.2

ip route 10.91.0.22 255.255.255.255 1.22.0.2

ip route 10.91.0.23 255.255.255.255 1.23.0.2

ip route 10.91.0.24 255.255.255.255 1.24.0.2

ip route 10.91.0.25 255.255.255.255 1.25.0.2

ip route 10.91.0.26 255.255.255.255 1.26.0.2

ip route 10.91.0.27 255.255.255.255 1.27.0.2

ip route 10.91.0.28 255.255.255.255 1.28.0.2

ip route 10.91.0.29 255.255.255.255 1.29.0.2

ip route 10.91.0.30 255.255.255.255 1.30.0.2

ip route 172.18.0.0 255.255.0.0 Ethernet3/1

!

dialer-list 1 protocol ip permit

!

line con 0

exec-timeout 0 0

transport input none

The following example configures the lines associated with the digital modems:

line 96 125

exec-timeout 0 0

modem InOut

transport input all

stopbits 1

flowcontrol hardware

line aux 0

exec-timeout 0 0

line vty 0 4

exec-timeout 0 0

password lab

login

line vty 5 60

exec-timeout 0 0

password lab

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007–2009 Cisco Systems, Inc. All rights reserved

Configuring X.25 on ISDN

This chapter describes how to configure X.25 on ISDN. It includes the following main sections:

- X.25 on ISDN Overview

- How to Configure X.25 on ISDN

- Configuration Examples for X.25 on ISDN

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

X.25 on ISDN Overview

BRI is an ISDN interface, and it consists of two B channels (B1 and B2) and one D channel. The B channels are used to transfer data, voice, and video. The D channel controls the B channels.

ISDN uses the D channel to carry signal information. ISDN can also use the D channel in a BRI to carry X.25 packets. The D channel has a capacity of 16 kbps, and the X.25 over D channel can utilize up to 9.6 kbps.

X.25-over-D-Channel Logical Interface

When X.25 on ISDN is configured, a separate X.25-over-D-channel logical interface is created. You can set its parameters without disrupting the original ISDN interface configuration. The original BRI interface will continue to represent the D, B1, and B2 channels.

Because some end-user equipment uses static terminal endpoint identifiers (TEIs) to access this feature, static TEIs are supported. The dialer understands the X.25-over-D-channel calls and initiates them on a new interface.

X.25 traffic over the D channel can be used as a primary interface where low-volume, sporadic interactive traffic is the normal mode of operation. Supported traffic includes the Internet Protocol Exchange (IPX), AppleTalk, transparent bridging, Xerox Network Systems (XNS), DECnet, and IP.

This feature is not available on the ISDN PRI.

Note X.25 on ISDN is also supported using the ISDN Always On/Dynamic (AO/DI) feature. AO/DI uses the Multilink PPP (MLP) protocol signaling with standard Q.922 and X.25 encapsulations, and can additionally use the Bandwidth Allocation Control Protocol (BACP) to optimize bandwidth on demand. For information about how to configure AO/DI, see the chapter “Configuring X.25 on ISDN Using AO/DI” in this publication.

Outbound Circuit-Switched X.25 Support over a Dialer Interface

Current Cisco IOS software enablescircuit-switched X.25 clients—PAD, X.25 switching, and Qualified Logical Link Control (QLLC)—to initiate calls and dynamically bring the X.25 context (which runs the X.25 protocol) up or down as needed. This capability allows packet-switched traffic over ISDN.

In earlier releases of the Cisco IOS software, X.25 circuit-switched clients were required to do an X.25 route lookup to forward a call. If the lookup resulted in a route to a dialer interface, the client would check the X.25 protocol state on the dialer interface. If the interface was not already bound to run the X.25 protocol, the software would reroute the call instead of bringing up a link and running the X.25 protocol. With this new feature, the X.25 context is dynamically created on demand and then removed when the X.25 session is cleared on the dialer interface.

For dialer profile interfaces, the X.25 context is created on the dialer interface, because X.25 protocol functions run on the dialer interface itself. Member links act like forwarding devices, because their topmost interface runs the actual encapsulated protocol. But for legacy dialer interfaces, the X.25 context is created on the member links once they come up and bind to a dialer.

There are no specific configuration tasks required to enable outbound circuit-switched X.25 support. See the “Outbound Circuit-Switched X.25 Example” example in the section “Configuration Examples for X.25 on ISDN” at the end of this chapter for an example of how to make use of this feature in your network.

How to Configure X.25 on ISDN

You can configure X.25 on ISDN in three ways:

- If the ISDN traffic will cross an X.25 network, you configure the ISDN interface as described in the “Setting Up Basic ISDN Services” and “Configuring signaling on T1 and E1” chapters earlier in this publication. Make certain to configure that ISDN interface for X.25 addressing and encapsulation as described in the “Configuring X.25” chapter of the Cisco IOS Wide-Area Networking Configuration Guide .

- Configure dynamic X.25 as illustrated in the section “Outbound Circuit-Switched X.25 Example” later in this chapter.

- If the D channel of an ISDN BRI interface is to carry X.25 traffic, perform the task described in the next section, “Configuring X.25 on the ISDN D Channel.”

Configuring X.25 on the ISDN D Channel

To configure an ISDN BRI interface (and create a special ISDN interface) to carry X.25 traffic on the D channel, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Specifies an ISDN BRI interface and begins interface configuration mode.

Step 2

Specifies a static TEI, if required by the switch.

Step 3

Creates a configurable interface for X.25 traffic over the ISDN D channel.

, Release 12.2, for the commands and tasks.

, Release 12.2.

Note The encapsulation x25 command is neither required nor used on this new interface, but other X.25 commands can be used to configure this interface.

command.

See the section “X.25 on ISDN D-Channel Configuration Example” at the end of this chapter for a configuration example.

Configuration Examples for X.25 on ISDN

This section illustrates X.25 on ISDN with the following examples:

- X.25 on ISDN D-Channel Configuration Example

- Outbound Circuit-Switched X.25 Example

X.25 on ISDN D-Channel Configuration Example

The following example creates a BRI 0:0 interface for X.25 traffic over the D channel and then configures the new interface to carry X.25 traffic:

interface bri0

isdn x25 dchannel

isdn x25 static-tei 8

!

interface bri0:0

ip address 10.1.1.2 255.255.255.0

x25 address 31107000000100

x25 htc 1

x25 suppress-calling-address

x25 facility windowsize 2 2

x25 facility packetsize 256 256

x25 facility throughput 9600 9600

x25 map ip 10.1.1.3 31107000000200

Outbound Circuit-Switched X.25 Example

The following example shows how to configure dynamic X.25 on an ISDN interface. Figure 1 illustrates the configuration.

Figure 1 Dynamic X.25 over ISDN

Configuration for Yen

version 12.0(5)T

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

service udp-small-servers

service tcp-small-servers

!

hostname yen

!

enable secret 5 $1$K32j$4AZW2oMDivpUeuMa/Fdcd.

enable password secret

!

username peso password 0 cisco

username dinar password 0 cisco

ip subnet-zero

no ip domain-lookup

ip domain-name cicso.com

ip name-server 172.18.1.148

!

isdn switch-type basic-5ess

x25 routing

!

interface Loopback0

no ip address

no ip directed-broadcast

no ip mroute-cache

!

interface Ethernet0

ip address 172.21.75.2 255.255.255.0

no ip directed-broadcast

no ip mroute-cache

media-type 10BaseT

!

interface BRI1

no ip address

no ip directed-broadcast

no ip mroute-cache

dialer pool-member 1

isdn switch-type basic-5ess

no fair-queue

!

interface Dialer0

ip address 10.1.1.1 255.0.0.0

no ip directed-broadcast

encapsulation x25

no ip mroute-cache

dialer remote-name dinar

dialer idle-timeout 180

dialer string 81060

dialer caller 81060

dialer max-call 1

dialer pool 1

dialer-group 1

x25 address 11111

x25 map ip 10.1.1.2 22222

!

ip default-gateway 172.21.75.1

no ip classless

ip route 0.0.0.0 0.0.0.0 172.21.75.1

no ip http server

!

access-list 101 permit ip any any

dialer-list 1 protocol ip list 101

!

x25 route 22222 interface Dialer0

x25 route 33333 interface Dialer0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

transport input all

line vty 0 4

password cisco

login

line vty 5 100

password cisco

login

!

end

Configuration for Peso Acting as X.25 Switch

version 12.0(5)T

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname peso

!

enable secret 5 $1$.Q00$h3vIhbOwO1fPvA2LYx2gE.

enable password cisco

!

ip subnet-zero

!

isdn switch-type primary-5ess

x25 routing

!

controller T1 0

cablelength short

cablelength short 133

!

controller T1 1

framing esf

clock source line primary

pri-group timeslots 1-24

!

controller T1 2

cablelength short

cablelength short 133

!

controller T1 3

cablelength short

cablelength short 133

!

interface Ethernet0

ip address 172.21.75.3 255.255.255.0

no ip directed-broadcast

!

interface Serial1:23

no ip address

no ip directed-broadcast

encapsulation ppp

dialer pool-member 1

isdn switch-type primary-5ess

isdn incoming-voice modem

no fair-queue

no cdp enable

ppp authentication chap

!

interface Dialer0

no ip address

no ip directed-broadcast

encapsulation x25 dce

no ip mroute-cache

dialer remote-name yen

dialer idle-timeout 180

dialer string 61401

dialer caller 61401

dialer max-call 1

dialer pool 1

x25 address 33333

!

interface Dialer1

no ip address

no ip directed-broadcast

encapsulation x25 dce

no ip mroute-cache

dialer remote-name dinar

dialer idle-timeout 180

dialer string 61403

dialer caller 61403

dialer max-call 1

dialer pool 1

x25 address 44444

!

ip default-gateway 172.21.75.1

no ip classless

ip route 0.0.0.0 0.0.0.0 172.21.75.1

no ip http server

!

x25 route 11111 interface Dialer0

x25 route 22222 interface Dialer1

x25 route source 11111 interface Dialer1

x25 route input-interface Dialer0 interface Dialer1

!

line con 0

transport input none

line 1 48

line aux 0

line vty 0 4

password cisco

login

line vty 5 100

password cisco

login

!

end

Configuration for Dinar

version 12.0(5)T

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname dinar

!

logging buffered 16384 debugging

enable secret 5 $1$8EjF$4.S0AoMOVa5OIAYEMrrFI/

enable password cisco

!

username yen password 0 cisco

username 7701

username drachma password 0 cisco

username AODI password 0 cisco

ip subnet-zero

ip rcmd rcp-enable

ip rcmd rsh-enable

ip rcmd remote-username atirumal

!

isdn switch-type basic-5ess

x25 routing

!

controller T1 0/0

!

interface BRI3/1

no ip address

no ip directed-broadcast

no ip mroute-cache

dialer pool-member 1

isdn switch-type basic-5ess

no fair-queue

!

interface Dialer0

ip address 10.1.1.2 255.0.0.0

no ip directed-broadcast

encapsulation x25

no ip mroute-cache

dialer remote-name yen

dialer idle-timeout 180

dialer string 81060

dialer caller 81060

dialer max-call 1

dialer pool 1

dialer-group 1

x25 address 22222

x25 map ip 10.1.1.1 11111

!

interface Dialer1

ip address 10.1.1.10 255.0.0.0

no ip directed-broadcast

no ip mroute-cache

dialer in-band

dialer-group 1

no fair-queue

!

ip default-gateway 172.21.75.1

no ip classless

ip route 0.0.0.0 0.0.0.0 172.21.75.1

no ip http server

!

access-list 101 permit ip any any

dialer-list 1 protocol ip list 101

!

x25 route 11111 interface Dialer0

x25 route 44444 interface Dialer0

!

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001–2009 Cisco Systems, Inc. All rights reserved.

Configuring X.25 on ISDN Using AO/DI

The chapter describes how to configure the X.25 on ISDN using the Always On/Dynamic ISDN (AO/DI) feature. It includes the following main sections:

- AO/DI Overview

- How to Configure an AO/DI Interface

- How to Configure an AO/DI Client/Server

- Configuration Examples for AO/DI

AO/DI supports PPP encapsulation on switched X.25 virtual circuits (VCs) only.

The X.25 encapsulation (per RFC 1356), PPP, Bandwidth Allocation Control Protocol (BACP), and Bandwidth Allocation Protocol (BAP) modules must be present in both the AO/DI client and server.

AO/DI relies on features from X.25, PPP, and BACP modules and must be configured on both the AO/DI client and server. BAP, if negotiated, is a subset of BACP, which is responsible for bandwidth allocation for the Multilink PPP (MLP) peers. It is recommended you configure MLP with the BAP option due to the differences between the ISDN (E.164) and X.25 (X.121) numbering formats.

To implement AO/DI, you must configure the AO/DI client and server for PPP, incorporating BAP and X.25 module commands. This task involves configuring the BRI or PRI interfaces with the appropriate X.25 commands and the dialer interfaces with the necessary PPP or BAP commands.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

, Release 12.2. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

AO/DI Overview

AO/DI functionality is based on the technology modules described in the following sections:

- PPP over X.25 Encapsulation

- Multilink PPP Bundle

- BACP/BAP

AO/DI is an on-demand service that is designed to optimize the use of an existing ISDN signaling channel (D channel) to transport X.25 traffic. The X.25 D-channel call is placed from the subscriber to the packet data service provider. The use of PPP allows protocols to be encapsulated within the X.25 logical circuit carried by the D channel. The bearer channels (B channels) use the multilink protocol without the standard Q.922 and X.25 encapsulations, and invoke additional bandwidth as needed. Optionally, BACP and BAP can be used to negotiate bandwidth allocation as required.

AO/DI takes full advantage of existing packet handlers at the central office by using an existing D channel to transport the X.25 traffic. The link associated with the X.25 D channel packet connection is used as the primary link of the multilink bundle. The D channel is a connectionless, packet-oriented link between the customer premise equipment (CPE) and the central office. Because the D channel is always available, it is possible to in turn offer “always available” services. On-demand functionality is achieved by using the B channels to temporarily boost data throughput and by disconnecting them after use. Figure 1 shows the AO/DI environment and how ISDN and X.25 resources are implemented.

Note On the client side, the X.25 switched virtual circuit (SVC) can only be terminated on an ISDN D channel; however, on the server side, the SVC can be terminated on an ISDN BRI using a D channel, a PRI using specific time slots, or a high-speed serial link.

Figure 1 AO/DI Environment

AO/DI provides the following benefits:

- ISDN telecommuting cost savings. Low-speed, D-channel services are typically more cost-efficient than the time-based tariffs applied to the B channels, which usually carry user data.

- Reductions in the amount of data traffic from service provider voice networks. The D-channel X.25 packets are handled at the central office by the X.25 packet handler, thereby routing these packets bypassing the switch, which reduces impact on the telephony network.

- Network access server cost reductions. AO/DI can reduce service provider network access server costs by increasing port efficiencies. Initial use of the “always on” D-channel connection lowers the contention ratio on standard circuit switched dial ports. (See Figure 2.)

Figure 2 Increasing Port Efficiency with AO/DI

PPP over X.25 Encapsulation

PPP over X.25 is accomplished through the following process:

1. The X.25 map statement on the client side creates a virtual access interface. A virtual access interface is dynamically created and configured by cloning the configuration from a dialer interface (dialer interface 1, for example).

2. The dialer interface goes into “spoofing” mode and stays in this mode until interesting traffic is seen.

command.

4. When the AO/DI server receives a call intended for its X.25 map statement, the call is accepted and an event is queued to the X.25 encapsulation manager. The encapsulation manager is an X.25 process that authenticates incoming X.25 calls and AO/DI events, and creates a virtual access interface that clones the configuration from the dialer or BRI interface. Figure 3 shows the virtual interface creation process.

Figure 3 Creating a Virtual Access Interface

Multilink PPP Bundle

The multilink protocol offers load balancing, packet fragmentation, and the bandwidth allocation functionality that is key to AO/DI structure. The MLP bundle process is achieved through the following process:

command initiates MLP and, subsequently, BAP. The virtual access interface that is created above the X.25 VC (over the D channel) becomes the first member link of the MLP bundle.

command in order to add B channels as needed to boost traffic throughput. When a B channel is added, the first member link enters “receive only” mode, allowing the link additions. When the higher throughput is no longer needed, the additional B channels are disconnected and the primary link is the only link in the bundle, the bundle disengages “receive only” mode. The X.25 SVC stays active. Figure 4 shows the MLP bundle sequence.

Figure 4 MLP Bundle Creation Sequence

MLP Encapsulation Enhancements

In previous releases of the Cisco IOS software, when MLP was used in a dialer profile, a virtual access interface was always created as the bundle. It was bound to both the B channel and the dialer profile interfaces after creation and cloning. The dialer profile interface could act as the bundle without help from a virtual access interface. But with recent software enhancements, it is no longer the virtual access interface that is added into the connected group of the dialer profile, but the dialer profile itself. The dialer profile becomes a connected member of its own connected group.

BACP/BAP

Bandwidth resources are provided by BACP, described in RFC 2125. Once the MLP peers have successfully negotiated BACP, BAP negotiates bandwidth resources in order to support traffic throughput. BAP is a subset of BACP, and it defines the methods and governing rules for adding and removing links from the bundle for MLP. BACP/BAP negotiations are achieved through the following process:

1. Once the MLP session is initiated and BACP is negotiated over the MLP bundle, the AO/DI client issues a BAP call request for additional bandwidth.

2. The AO/DI server responds with the BAP call response, which contains the phone number of the B channel to add. B channels are added, as needed, to support the demand for increased traffic throughput.

3. B channels are disconnected as the traffic load decreases.

How to Configure an AO/DI Interface

To configure X.25 on ISDN using AO/DI, perform the following tasks:

- Configuring PPP and BAP on the Client (As required)

- Configuring X.25 Parameters on the Client (As required)

- Configuring PPP and BAP on the Server (As required)

- Configuring X.25 Parameters on the Server (As required)

For examples of how to configure X.25 on ISDN using AO/DI in your network, see the section “Configuration Examples for AO/DI” at the end of this chapter.

Configuring PPP and BAP on the Client

To configure PPP and BAP under the dialer interface on the AO/DI client, use the following commands in interface configuration mode as needed:

Command

Purpose

Enables PPP BACP bandwidth allocation negotiation.

Enables PPP on the interface.

Enables dial-on-demand routing (DDR) on the interface.

Sets the dialer load threshold.

Controls access to this interface by adding it to a dialer access group.

(Optional) Enables the interface to initiate additional links upon peer request.

Enables the interface to initiate additional links.

]

or

]

class-name]

Enables a serial interface or an ISDN interface to initiate and receive calls to or from remote sites.

Specifies the destination string (telephone number) for calling:

- A single site (using legacy DDR)

- Multiple sites (using dialer profiles)

Configuring X.25 Parameters on the Client

The AO/DI client interface must be configured to run PPP over X.25. To configure the interface for the X.25 parameters, use the following commands in interface configuration mode as needed:

Command

Purpose

Configures the X.25 address.

Sets the highest two-way circuit number. For X.25 the default is 1024.

Sets the default VC receive window size. The default is 2 packets.1

1.The default input and output window sizes are typically defined by your network administrator. Cisco IOS configured window sizes must be set to match the window size of the network.

1.The default input and output window sizes are typically defined by your network administrator. Cisco IOS configured window sizes must be set to match the window size of the network.

Command Reference.

Configuring PPP and BAP on the Server

To configure PPP and BAP under the dialer interface on the AO/DI server, use the following commands in interface configuration mode as needed:

Command

Purpose

Enables PPP BACP bandwidth allocation negotiation.

Enables PPP on the interface.

Enables DDR on the interface.

Sets the dialer load threshold.

Controls access to this interface by adding it to a dialer access group.

Enables the interface to accept additional links upon peer request.

Enables the interface to initiate additional links (optional).

BAP configuration commands are optional. For information on how to configure BACP/BAP see the chapter “Configuring BACP” later in this publication.

Configuring X.25 Parameters on the Server

The AO/DI server BRI, PRI, or serial interface must be configured for the X.25 parameters necessary to run PPP over X.25. To configure the interface for X.25 parameters, use the following commands in interface configuration mode as needed:

Command

Purpose

Configures the X.25 address.

Sets the highest two-way circuit number. For X.25 the default is 1024.

Sets the default VC receive window size. The default is 2 packets.2

2.The default input and output window sizes are typically defined by your network administrator. Cisco IOS configured window sizes must be sets to match the window size of the network.

2.The default input and output window sizes are typically defined by your network administrator. Cisco IOS configured window sizes must be sets to match the window size of the network.

Command Reference.

How to Configure an AO/DI Client/Server

Once the AO/DI client and server are configured with the necessary PPP, BAP, and X.25 commands, configure the routers to perform AO/DI. Perform the tasks in the following sections:

- Configuring the AO/DI Client (Required)

- Configuring the AO/DI Server (Required)

Configuring the AO/DI Client

To configure AO/DI, you must complete the tasks in the following section. The last task, to define local number peer characteristics, is optional.

- Enabling AO/DI on the Interface (Required)

- Enabling the AO/DI Interface to Initiate Client Calls (Required)

- Enabling the MLP Bundle to Add Multiple Links (Required)

- Modifying BACP Default Settings (Optional)

See the section “AO/DI Client Configuration Example” at the end of this chapter for an example of how to configure the AO/DI client.

Enabling AO/DI on the Interface

To enable an interface to run the AO/DI client, use the following command in interface configuration mode:

Command

Purpose

Enables the AO/DI client on an interface.

Enabling the AO/DI Interface to Initiate Client Calls

You must enable the interface to establish a PPP session over the X.25 protocol. The cloning interface will hold the PPP configuration, which will be cloned by the virtual access interface that is created and attached to the X.25 VC. The cloning interface must also hold the MLP configuration that is needed to run AO/DI.

To add the X.25 map statement that will enable the PPP session over X.25, identify the cloning interface, and configure the interface to initiate AO/DI calls, use the following command in interface configuration mode:

Command

Purpose

Enables the interface to initiate a PPP session over the X.25 protocol and remote end mapping.

Enabling the MLP Bundle to Add Multiple Links

value), the MLP bundle will add member links (B channels). The addition of another B channel places the first link member into “receive-only” mode and subsequent links are added, as needed.

To configure the dialer interface or BRI interface used for cloning purposes and to place the first link member into receive only mode, use the following command in interface configuration mode:

Command

Purpose

Configures the interface to enter “receive only” mode so that MLP links are added as needed.

Modifying BACP Default Settings

During BACP negotiation between peers, the called party indicates the number to call for BACP. This number may be in either a national or subscriber format. A national format indicates that the phone number returned from the server to the client should contain ten digits. A subscriber number format contains seven digits.

To assign a prefix to the phone number that is to be returned, use the following optional command in interface configuration mode:

Command

Purpose

(Optional) specifies a primary telephone number prefix for a peer to call for PPP BACP negotiation.

Note The ppp bap number prefix command is not typically required on the server side, as the server usually does not initiate calls to the client. This command would only be used on the server in a scenario where both sides are configured to act as both client and server.

Configuring the AO/DI Server

command to ensure calls are not originated by the interface. Use the commands in the following sections to configure the AO/DI server:

- Enabling the Interface to Receive AO/DI Client Calls (Required)

- Enabling the MLP Bundle to Add Multiple Links (Required)

- Modifying BACP Default Settings (Optional)

See the section “AO/DI Server Configuration Example” at the end of this chapter for an example of how to configure the AO/DI server.

Enabling the Interface to Receive AO/DI Client Calls

option must be set in order to ensure that calls do not originate from this interface.

To configure an interface for AO/DI server, use the following command in interface configuration mode:

Command

Purpose

Enables the interface to initiate a PPP session over the X.25 protocol and remote end mapping.

Enabling the MLP Bundle to Add Multiple Links

value), the MLP bundle will add member links (B channels). The addition of another B channel places the first link member into “receive-only” mode and subsequent links are added, as needed.

To configure the dialer interface or BRI interface used for cloning purposes and to place the first link member into receive only mode, use the following command in interface configuration mode:

Command

Purpose

Configures the interface to enter “receive only” mode so that MLP links are added as needed.

Modifying BACP Default Settings

During BACP negotiation between peers, the called party indicates the number to call for BACP. This number may be in either a national or subscriber format. A national format indicates that the phone number returned from the server to the client should contain 10 digits. A subscriber number format contains 7 digits.

To assign a prefix to the phone number that is to be returned, use the following, optional command in interface configuration mode:

Command

Purpose

}

(Optional) Specifies that the primary telephone number for a peer to call is in either a national or subscriber number format.

Note The ppp bap number prefix command is not typically required on the server side, because the server usually does not initiate calls to the client. This command would only be used on the server in a scenario where both sides are configured to act as both client and server.

Configuration Examples for AO/DI

This section provides the following configuration examples:

- AO/DI Client Configuration Example

- AO/DI Server Configuration Example

AO/DI Client Configuration Example

The following example shows BRI interface 0 configured with the PPP, multilink, and X.25 commands necessary for the AO/DI client:

hostname Router_client

!

ip address-pool local

isdn switch-type basic-5ess

x25 routing

!

interface Ethernet0

ip address 172.21.71.99 255.255.255.0

!

interface BRI0

isdn switch-type basic-5ess

ip address 10.1.1.9 255.0.0.0

encap ppp

dialer in-band

dialer load-threshold 1 either

dialer-group 1

no fair-queue

ppp authentication chap

ppp multilink bap

ppp bap callback accept

ppp bap call request

ppp bap number prefix 91

ppp multilink idle-link

isdn x25 static-tei 23

isdn x25 dchannel

dialer rotary-group 1

!

interface BRI0:0

no ip address

x25 address 12135551234

x25 aodi

x25 htc 4

x25 win 3

x25 wout 3

x25 map ppp 12135556789 interface bri0

!

dialer-list 1 protocol ip permit

AO/DI Server Configuration Example

format.

hostname Router_server

!

ip address-pool local

isdn switch-type basic-5ess

x25 routing

!

interface Ethernet0

ip address 172.21.71.100 255.255.255.0

!

interface BRI0

isdn switch-type basic-5ess

ip address 10.1.1.10 255.0.0.0

encap ppp

dialer in-band

no fair-queue

dialer load-threshold 1 either

dialer-group 1

ppp authentication pap

ppp multilink bap

ppp multilink idle-link

ppp bap number default 2135550904

ppp bap number format national

ppp bap call accept

ppp bap timeout pending 20

isdn x25 static-tei 23

isdn x25 dchannel

dialer rotary-group 1

!

interface BRI0:0

no ip address

x25 address 12135556789

x25 htc 4

x25 win 3

x25 wout 3

x25 map ppp 12135551234 interface bri0 no-outgoing

!

dialer

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001–2009 Cisco Systems, Inc. All rights reserved.

Configuring ISDN on Cisco 800 Series Routers

This chapter describes the Common Application Programming Interface (CAPI) and Remote Common Application Programming Interface (RCAPI) feature for the Cisco 800 series routers. This information is included in the following main sections:

- CAPI and RCAPI Overview

- How to Configure RCAPI

- Configuration Examples for RCAPI

The CAPI is an application programming interface standard used to access ISDN equipment connected to ISDN BRIs and ISDN PRIs. RCAPI is the CAPI feature configured remotely from a PC client.

Before you can enable the RCAPI feature on the Cisco 800 series router, the following requirements must be met:

- Cisco 800 series software with RCAPI support is installed on the router.

- CAPI commands are properly configured on the router.

- Both the CAPI local device console and RCAPI client devices on the LAN are correctly installed and configured with RVS-COM client driver software.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

CAPI and RCAPI Overview

Figure 1 shows how CAPI connects applications, drivers, and controllers.

Figure 1 CAPI Connections

Framing Protocols

The framing protocols supported by CAPI include High-Level Data Link Control (HDLC), HDLC inverted, bit transparent (speech), and V.110 synchronous/asynchronous.

Data Link and Network Layer Protocols

CAPI integrates the following data link and network layer protocols:

- Link Access Procedure on the D-channel (LAPD) in accordance with Q.921 for X.25 D-channel implementation

- PPP

- ISO 8208 (X.25 DTE-DTE)

- X.25 DCE, T.90NL, and T.30 (fax group 3)

CAPI Features

CAPI supports the following features:

- Basic call features, such as call setup and tear-down

- Multiple B channels for data and voice connections

- Multiple logical data link connections within a physical connection

- Selection of different services and protocols during connection setup and on answering incoming calls

- Transparent interface for protocols above Layer 3

- One or more BRIs as well as PRI on one or more Integrated Services Digital Network (ISDN) adapters

- Multiple applications

- Operating-systems-independent messages

- Operating-system-dependent exchange mechanism for optimum operating system integration

- Asynchronous event-driven mechanism, resulting in high throughput

- Well-defined mechanism for manufacturer-specific extensions

- Multiple supplementary services

Figure 2 shows the components of the RCAPI implementation.

Figure 2 Components of RCAPI

CAPI provides a standardized interface through which application programs can use ISDN drivers and controllers. One application can use one or more controllers. Several applications can share one or more controllers.

CAPI supplies a selection mechanism that supports applications that use protocols at different levels and standardized network access. An abstraction from different protocol variables is performed to provide this support. All connection-related data, such as connection state and display messages, is available to the applications at any time.

Supported B-Channel Protocols

The router provides two 64-kbps B channels to RCAPI clients. Each B channel can be configured separately to work in either HDLC mode or bit transparent mode. For CAPI support, layers B2 through B7 protocols are transparent to the applications using these B channels.

The ISDN Core Engine of RVS-COM supports the following B-channel protocols:

- CAPI layer B1

– 64-kbps with HDLC framing

– 64-kbps bit transparent operation with byte framing from the network

– T.30 modem for fax group 3

– Modem with full negotiation

- CAPI layer B2

– V.120

– Transparent

– T.30 modem for fax group 3

– Modem with full negotiation

- CAPI layer B3

– Transparent

– T.90NL with compatibility to T.70NL according to T.90 Appendix II

– ISO 8208 (X.25 DTE-DTE) modulo 8 and windows size 2, no multiple logical connections

– T.30 for fax group 3

– Modem with full negotiation

- T.30 for fax group 3 (SFF file format [default], sending and receiving up to 14400 bit/s with ECM option, modulations V.17, V.21, V.27ter, V.29)

- Analog modem (sending and receiving up to 14,400 bit/s, modulations V.21, V.22, V.22bis, V.23, V.32, V.32bis)

Supported Switch Types

CAPI and RCAPI support is available only for the ISDN switch type Net3.

CAPI and RVS-COM

The router supports the ISDN Device Control Protocol (ISDN-DCP) from RVS-COM. ISDN-DCP allows a workstation on the LAN or router to use legacy dial computer telephony integration (CTI) applications. These applications include placing and receiving telephone calls and transmitting and receiving faxes.

Using ISDN-DCP, the router acts as a DCP server. By default, the router listens for DCP messages on TCP port number 2578 (the Internet-assigned number for RVS-COM DCP) on its LAN port.

When the router receives a DCP message from a DCP client (connected to the LAN port of the router), the router processes the message and acts on it; it can send confirmations to the DCP clients and ISDN packets through the BRI port of the router.

When the router receives packets destined for one of the DCP clients on its BRI port, the router formats the packet as a DCP message and sends it to the corresponding client. The router supports all the DCP messages specified in the ISDN-DCP specifications defined by RVS-COM.

Supported Applications

ISDN-DCP supports CAPI and non-CAPI applications. Applications are supported that use one or two B channels for data transfer, different HDLC-based protocols, Euro File transfer, or G4 fax; also supported are applications that send bit-transparent data such as A/Mu law audio, G3 fax, analog modem, or analog telephones.

How to Configure RCAPI

To configure RCAPI, perform the tasks in the following sections:

- Configuring RCAPI on the Cisco 800 Series Router (Required)

- Monitoring and Maintaining RCAPI (Optional)

- Troubleshooting RCAPI (Optional)

Configuring RCAPI on the Cisco 800 Series Router

To configure RCAPI on the Cisco 800 series router, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Router(config)# isdn switch-type basic-net3

Sets the switch type. In this example, the switch type is set to NET3 ISDN, which covers the Euro-ISDN E-DSS1 signaling system and is ETSI-compliant.

Step 2

Router(config)# rcapi number number

Enters the RCAPI directory number assigned by the ISDN provider for the device.

An example command:

rcapi number 12345 .

Step 3

Router(config)# rcapi server port number

command is mandatory for RCAPI to be enabled on the router. The parameter port is optional and is entered only when you need to specify a port number for RCAPI functions. Otherwise, the default port 2578 is used.

An example command with default port 2578:

rcapi server port

An example command with port 2000:

rcapi server port 2000

Configure the same number on both the router and the client PC.

Step 4

Router(config)# interface bri0

Configures the ISDN BRI interface and begins interface configuration mode.

Step 5

Router(config-if)# isdn switch-type basic-net3

Sets the switch type for the bri0 interface. In this example, the switch type is set to NET3 ISDN, which covers the Euro-ISDN E-DSS1 signaling system and is ETSI-compliant.

Step 6

Router(config-if)# isdn incoming-voice modem

Sets the modem as the default handler for incoming voice calls.

Note If required, at each remote device console change to global configuration mode, using the command configure terminal, and repeat Step 2 through Step 7 to configure that device.

Monitoring and Maintaining RCAPI

To monitor and maintain RCAPI, use the following command in privileged EXEC mode:

Command

Purpose

Router# show rcapi status

Displays RCAPI status.

Troubleshooting RCAPI

To test the RCAPI operation, use the following command in privileged EXEC mode

Command

Purpose

Router# debug rcapi events

Starts a background debug program.

Configuration Examples for RCAPI

The following configuration output example shows two Cisco 800 series routers configured for RCAPI:

Router 1

Router1# show running-config

Building configuration...

Current configuration:

!

version xx.x

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname local

!

ip subnet-zero

!

isdn switch-type basic-net3

isdn voice-call-failure 0

!

interface Ethernet0

ip address 192.168.2.1 255.255.255.0

no ip directed-broadcast

!

interface BRI0

no ip address

no ip directed-broadcast

isdn switch-type basic-net3

isdn incoming-voice modem

!

no ip http server

ip classless

!

line con 0

transport input none

stopbits 1

line vty 0 4

!

rcapi server port 2578

!

rcapi number 5551000

rcapi number 5553000

!

end

Router1#

Router 2

Router2# show running-config

Building configuration...

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname local

!

ip subnet-zero

!

isdn switch-type basic-net3

isdn voice-call-failure 0

!

interface Ethernet0

ip address 192.168.1.1 255.255.255.0

no ip directed-broadcast

!

interface BRI0

no ip address

no ip directed-broadcast

isdn switch-type basic-net3

isdn incoming-voice modem

!

no ip http server

ip classless

!

line con 0

transport input none

stopbits 1

line vty 0

!

rcapi server port 2578

!

rcapi number 5552000

rcapi number 5554000

!

end

Router2#

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2007–2009 Cisco Systems, Inc. All rights reserved.

Cisco IOS Software Feature Removal

Feature History

Release

Modification

12.2(13)T

Features described in this feature module were removed in 12.2(13)T.

12.2(15)T

Features described in this feature module were removed in 12.2(15)T.

Feature Overview

The Cisco IOS Software Feature Removal feature is an engineering project to permanently remove selected legacy features (or components) from the Cisco IOS code. These features will not be available in future releases of Cisco IOS software.

The legacy features that have been removed as of Release 12.2(13)T are as follows:

- AppleTalk EIGRP

- Apollo Domain

- Banyan VINES

- Exterior Gateway Protocol

- HP Probe

- Interior Gateway Routing Protocol

- Next Hop Resolution Protocol for IPX

- Novell Link-State Protocol

- Simple Multicast Routing Protocol for AppleTalk

- Xerox Network Systems

The legacy features that have been removed as of Release 12.2(15)T are as follows:

- LAN Extension

- Netware Asychronous Services Interface Protocol

- Xremote

This feature module lists the commands that have been removed from or modified in Cisco IOS software with the removal of a specified feature.

Note Commands that have been modified may not all be listed in this document.

AppleTalk EIGRP

The following commands have been removed from or modified in Cisco IOS software with the removal of the AppleTalk EIGRP feature. Please note that not all commands that may have been modified are listed here:

- appletalk eigrp active-time

- appletalk eigrp-bandwidth-percentage

- appletalk eigrp log-neighbor-changes

- appletalk eigrp-splithorizon

- appletalk eigrp-timers

- appletalk route-redistribution

- debug apple eigrp-all

- show appletalk eigrp interfaces

- show appletalk eigrp neighbors

- show appletalk eigrp topology

Apollo Domain

The following commands have been removed from or modified in Cisco IOS software with the removal of the Apollo Domain feature:

- apollo access-group

- apollo access-list

- apollo maximum-paths

- apollo network

- apollo route

- apollo routing

- apollo update-time

- debug packet

- ping

- show apollo arp

- show apollo interface

- show apollo route

- show apollo traffic

Banyan VINES

The following commands have been removed from or modified in Cisco IOS software with the removal of the Banyan VINES feature:

- clear vines cache

- clear vines ipc

- clear vines neighbor

- clear vines route

- clear vines traffic

- debug frame-relay

- debug packet

- debug vines arp

- debug vines echo

- debug vines ipc

- debug vines netrpc

- debug vines packet

- debug vines routing

- debug vines service

- debug vines state

- debug vines table

- show vines access

- show vines cache

- show vines host

- show vines interface

- show vines ipc

- show vines neighbor

- show vines route

- show vines service

- show vines traffic

- trace (VINES)

- vines access-group

- vines access-list (extended)

- vines access-list (simple)

- vines access-list (standard)

- vines arp-enable

- vines decimal

- vines encapsulation

- vines enhancements

- vines host

- vines input-network-filter

- vines input-router-filter

- vines metric

- vines neighbor

- vines output-network-filter

- vines propagate

- vines redirect

- vines route

- vines route-cache

- vines routing

- vines serverless

- vines single-route

- vines split-horizon

- vines srtp-enabled

- vines time access-group

- vines time destination

- vines time participate

- vines time services

- vines time set-system

- vines time use-system

- vines update deltas

- vines update interval

Exterior Gateway Protocol

No commands were removed from or modified in Cisco IOS software with the removal of the EGP feature.

HP Probe

The following commands have been removed from or modified in Cisco IOS software with the removal of the HP Probe feature:

- arp (interface) probe

- ip hp-host

- ip probe proxy

Interior Gateway Routing Protocol

The following commands have been removed from or modified in Cisco IOS software with the removal of the IGRP feature:

- debug clns igrp packets

- debug ip igrp events

- debug ip igrp transactions

- debug ip routing

- default-metric (IGRP)

- ip split-horizon (IGRP)

- metric holddown

- metric maximum-hops

- metric weights (IGRP)

- neighbor (IGRP)

- network (IGRP)

- offset-list (IGRP)

- router igrp

- set metric (IGRP)

- timers basic (IGRP)

- traffic-share balanced

LAN Extension

No commands were removed from or modified in Cisco IOS software with the removal of the LAN Extension feature.

Netware Asychronous Services Interface Protocol

The following commands have been removed from or modified in Cisco IOS software with the removal of the NASI protocol:

- aaa authentication nasi

- ipx nasi-server enable

- nasi authentication

- show ipx nasi connections

Next Hop Resolution Protocol for IPX

The following commands have been removed from or modified in Cisco IOS software with the removal of the NHRP for IPX feature:

- clear ipx nhrp

- debug nhrp

- debug nhrp extension

- debug nhrp options

- debug nhrp packet

- debug nhrp rate

- ipx nhrp authentication

- ipx nhrp holdtime

- ipx nhrp interest

- ipx nhrp map

- ipx nhrp max-send

- ipx nhrp network-id

- ipx nhrp nhs

- ipx nhrp record

- ipx nhrp responder

- ipx nhrp use

- show ipx nhrp

- show ipx nhrp traffic

Novell Link-State Protocol

The following commands have been removed from or modified in Cisco IOS software with the removal of the NLSP feature:

- access-list (NLSP)

- area-address (NLSP)

- clear ipx nlsp neighbors

- clear ipx route

- clear ipx traffic

- deny (NLSP)

- distribute-list in

- distribute-list out

- distribute-sap-list in

- distribute-sap-list out

- ipx access-list

- ipx advertise-default-route-only

- ipx flooding-unthrottled

- ipx internal-network

- ipx nlsp csnp-interval

- ipx nlsp enable

- ipx nlsp hello-interval

- ipx nlsp hello-multiplier

- ipx nlsp lsp-interval

- ipx nlsp metric

- ipx nlsp multicast

- ipx nlsp priority

- ipx nlsp retransmit-interval

- ipx nlsp rip

- ipx nlsp sap

- ipx ping-default

- ipx potential-pseudonode

- ipx route

- ipx router

- log-adjacency-changes

- multicast (NLSP)

- permit (NLSP)

- redistribute (IPX)

- route-aggregation

- show ipx nlsp database

- show ipx nlsp neighbors

- show ipx nlsp spf-log

- show ipx route

- show ipx traffic

Simple Multicast Routing Protocol for AppleTalk

The following commands have been removed from or modified in Cisco IOS software with the removal of the SMRP for AppleTalk feature:

- clear smrp mcache

- debug smrp all

- debug smrp group

- debug smrp mcache

- debug smrp neighbor

- debug smrp port

- debug smrp route

- debug smrp transaction

- show smrp forward

- show smrp globals

- show smrp group

- show smrp mcache

- show smrp neighbor

- show smrp port

- show smrp route

- show smrp traffic

- smrp mroute-cache protocol appletalk

- smrp protocol appletalk

- smrp routing

Xerox Network Systems

The following commands have been removed from or modified in Cisco IOS software with the removal of the XNS feature:

- access-list (XNS extended)

- access-list (XNS standard)

- debug xns packet

- debug xns routing

- show xns cache

- show xns interface

- show xns route

- show xns traffic

- xns access-group

- xns encapsulation

- xns flood broadcast allnets

- xns flood broadcast net-zero

- xns flood specific allnets

- xns forward-protocol

- xns hear-rip

- xns helper-address

- xns input-network-filter

- xns maximum-paths

- xns network

- xns output-network-filter

- xns route

- xns route-cache

- xns router-filter

- xns routing

- xns ub-emulation

- xns update-time

Xremote

The following commands have been removed from or modified in Cisco IOS software with the removal of the Xremote feature:

- show xremote

- show xremote line

- xremote

- xremote lat

- xremote tftp buffersize

- xremote tftp host

- xremote tftp retries

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2007–2009 Cisco Systems, Inc. All rights reserved.

Configuring ISDN PRI

This chapter describes how to configure channelized E1 and channelized T1 for ISDN PRI and for two types of signaling to support analog calls over digital lines. This information is included in the following sections:

- Signaling Overview

- How to Configure ISDN PRI

- Monitoring and Maintaining ISDN PRI Interfaces

- How to Configure Robbed-Bit Signaling for Analog Calls over T1 Lines

- How to Configure CAS

- How to Configure Switched 56K Digital Dial-In over Channelized T1 and Robbed-Bit Signaling

- How to Configure Switched 56K Services

- How to Configure E1 R2 Signaling

- Enabling R1 Modified Signaling in Taiwan

- Configuration Examples for Channelized E1 and Channelized T1

, Release 12.2.

For hardware technical descriptions and for information about installing the controllers and interfaces, refer to the hardware installation and maintenance publication for your particular product.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

Signaling Overview

Channelized T1 and channelized E1 can be configured for ISDN PRI, synchronous serial, and asynchronous serial communications.

Channelized T1 and channelized E1 are supported by corresponding controllers. Each T1 or E1 controller has one physical network termination, but it can have many virtual interfaces, depending on the configuration.

In-Band and Out-of-Band Signaling

indicate whether various signals—which are used to set up, control, and terminate calls—travel in the same channel (or band) with voice calls or data made by the user, or whether those signals travel in a separate channel (or band).

ISDN, which uses the D channel for signaling and the B channels for user data, fits into the out-of-band signaling category.

Robbed-bit signaling, which uses bits from specified frames in the user data channel for signaling, fits into the in-band signaling category.

Channel-associated signaling (CAS), which uses E1 time slot 16 (the D channel) for signaling, fits into the out-of-band signaling category.

Channelized E1 and T1 on Cisco Devices

You can allocate the available channels for channelized E1 or T1 in the following ways:

- All channels can be configured to support ISDN PRI. Channelized T1 ISDN PRI offers 23 B channels and 1 D channel. Channelized E1 ISDN PRI offers 30 B channels and 1 D channel. Channel 24 is the D channel for T1, and channel 16 is the D channel for E1.

- If you are not running ISDN PRI, all channels can be configured to support robbed-bit signaling, which enables a Cisco modem to receive and send analog calls.

- All channels can be configured in a single channel group. For configuration information about this leased line or nondial use, see the “Configuring Serial Interfaces” chapter in the Cisco IOS Interface Configuration Guide .

- Mix and match channels supporting ISDN PRI and channel grouping.

- Mix and match channels supporting ISDN PRI, robbed-bit signaling, and channel grouping across the same T1 line. For example, on the same channelized T1 line you can configure the pri-group timeslots 1-10 command, channel-group 11 timeslots 11-16 command, and cas-group 17 timeslots 17-23 type e&m-fgb command. This is a rare configuration because it requires you to align the correct range of time slots on both ends of the connection.

See the sections “PRI Groups and Channel Groups on the Same Channelized T1 Controller Example,” “Robbed-Bit Signaling Examples,” and the “ISDN CAS Examples” at the end of this chapter.

How to Configure ISDN PRI

This section describes tasks that are required to get ISDN PRI up and running. This section does not address routing issues, dialer configuration, and dial backup. For information about those topics, see the chapters in the “Dial-on-Demand Routing” part of this manual.

To configure ISDN PRI, perform the tasks in the following sections:

- Requesting PRI Line and Switch Configuration from a Telco Service Provider (Required)

- Configuring Channelized E1 ISDN PRI (As required)

- Configuring Channelized T1 ISDN PRI (As required)

- Configuring the Serial Interface (Required)

- Configuring NSF Call-by-Call Support (Primary-4ESS Only)

- Configuring Multiple ISDN Switch Types (Optional)

- Configuring B Channel Outgoing Call Order (Optional)

- Performing Configuration Self-Tests (Optional)

See the section “Monitoring and Maintaining ISDN PRI Interfaces” later in this chapter for tips on maintaining the ISDN PRI interface. See the end of this chapter for the “ISDN PRI Examples” section.

Note After the ISDN PRI interface and lines are operational, configure the D-channel interface for dial-on-demand routing (DDR). The DDR configuration specifies the packets that can trigger outgoing calls, specifies whether to place or receive calls, and provides the protocol, address, and phone number to use.

Requesting PRI Line and Switch Configuration from a Telco Service Provider

Before configuring ISDN PRI on your Cisco router, you need to order a correctly provisioned ISDN PRI line from your telecommunications service provider.

This process varies dramatically from provider to provider on a national and international basis. However, some general guidelines follow:

- Verify if the outgoing B channel calls are made in ascending or descending order. Cisco IOS default is descending order however, if the switch from the service providers is configured for outgoing calls made in ascending order, the router can be configured to match the switch configuration of the service provider.

- Ask for delivery of calling line identification. Providers sometimes call this CLI or automatic number identification (ANI).

- If the router will be attached to an ISDN bus (to which other ISDN devices might be attached), ask for point-to-multipoint service (subaddressing is required) and a voice-and-data line.

provides a sample of the T1 configuration attributes you might request for a PRI switch used in North America.

Table 1 North American PRI Switch Configuration Attributes

Attribute

Value

Line format

Extended Superframe Format (ESF)

Line coding

Binary 8-zero substitution (B8ZS)

Call type

23 incoming channels and 23 outgoing channels

Speed

64 kbps

Call-by-call capability

Enabled

Channels

23 B + D

Trunk selection sequence

Either ascending order (from 1 to 23) or descending order (from 23 to 1)

B + D glare

Yield

Directory numbers

Only 1 directory number assigned by service provider

SPIDs required?

None

Configuring Channelized E1 ISDN PRI

To configure ISDN PRI on a channelized E1 controller, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

for a list of supported switch type keywords.)

Step 2

or

Defines the controller location in the Cisco 7200 or Cisco 7500 series router by slot and port number.

Defines the controller location in the Cisco 4000 series or the Cisco AS5200 universal access server by unit number.1

Step 3

Defines the framing characteristics as cyclic redundancy check 4 (CRC4).

Step 4

Defines the line code as high-density bipolar 3 (HDB3).

Step 5

]

Configures ISDN PRI.

1.Controller numbers range from 0 to 2 on the Cisco 4000 series and from 1 to 2 on the Cisco AS5000 series access server.

1.Controller numbers range from 0 to 2 on the Cisco 4000 series and from 1 to 2 on the Cisco AS5000 series access server.

.

lists the keywords for the supported service provider switch types to be used in Step 1 above.

Table 2 ISDN Service Provider PRI Switch Types

Switch Type Keywords

Description/Use

Voice/PBX Systems

command.

Australia and Europe

NET5 ISDN PRI switch types for Asia, Australia, and New Zealand; ETSI-compliant switches for Euro-ISDN E-DSS1 signaling system.

Japan

Japanese NTT ISDN PRI switches.

North America

Lucent (AT&T) 4ESS switch type for the United States.

Lucent (AT&T) 5ESS switch type for the United States.

Nortel DMS-100 switch type for the United States.

National ISDN switch type.

All Users

No switch defined.

Note For information and examples for configuring ISDN PRI for voice, video, and fax applications, refer to the Cisco IOS Voice, Video, and Fax Applications Configuration Guide.

Configuring Channelized T1 ISDN PRI

To configure ISDN PRI on a channelized T1 controller, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

for a list of supported PRI switch type keywords.)

Step 2

or

Specifies a T1 controller on a Cisco 7500.

Specifies a T1 controller on a Cisco 4000.2

Step 3

Defines the framing characteristics as Extended Superframe Format (ESF).

Step 4

Defines the line code as binary 8 zero substitution (B8ZS).

Step 5

]3

Configures ISDN PRI.

If you do not specify the time slots, the controller is configured for 23 B channels and 1 D channel.

2.Controller numbers range from 0 to 2 on the Cisco 4000 series and from 1 to 2 on the Cisco AS5000 series.

2.Controller numbers range from 0 to 2 on the Cisco 4000 series and from 1 to 2 on the Cisco AS5000 series.

3.On channelized T1, time slots range from 1 to 24. You can specify a range of time slots (for example, pri-group timeslots 12-24) if other time slots are used for non-PRI channel groups.

3.On channelized T1, time slots range from 1 to 24. You can specify a range of time slots (for example, pri-group timeslots 12-24) if other time slots are used for non-PRI channel groups.

.

Configuring the Serial Interface

When you configure ISDN PRI on the channelized E1 or channelized T1 controller, in effect you create a serial interface that corresponds to the PRI group time slots. This interface is a logical entity associated with the specific controller. After you create the serial interface by configuring the controller, you must configure the D channel serial interface. The configuration applies to all the PRI B channels (time slots).

To configure the D channel serial interface, perform the tasks in the following sections:

- Specifying an IP Address for the Interface (Required)

- Configuring Encapsulation on ISDN PRI (Required)

- Configuring Network Addressing (Required)

- Configuring ISDN Calling Number Identification (As Required)

- Overriding the Default TEI Value (As Required)

- Configuring a Static TEI (As Required)

- Configuring Incoming ISDN Modem Calls (As Required)

- Filtering Incoming ISDN Calls (As Required)

- Configuring the ISDN Guard Timer (Optional)

- Configuring Inclusion of the Sending Complete Information Element (Optional)

- Configuring ISDN PRI B-Channel Busyout (Optional)

Specifying an IP Address for the Interface

To configure the D channel serial interface created for ISDN PRI, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

or

Specifies D channel on the serial interface for channelized T1 and begins interface configuration mode.

Specifies D channel on the serial interface for channelized E1 and begins interface configuration mode.

Step 2

Specifies an IP address for the interface.

When you configure the D channel, its configuration is applied to all the individual B channels.

Configuring Encapsulation on ISDN PRI

PPP encapsulation is configured for most ISDN communication. However, the router might require a different encapsulation for traffic sent over a Frame Relay or X.25 network, or the router might need to communicate with devices that require a different encapsulation protocol.

Configure encapsulation as described in one of the following sections:

- Configuring PPP Encapsulation

- Configuring Encapsulation for Frame Relay or X.25 Networks

- Configuring Encapsulation for Combinet Compatibility

In addition, the router can be configured for automatic detection of encapsulation type on incoming calls. To configure this feature, complete the tasks in the “Configuring Automatic Detection of Encapsulation Type of Incoming Calls” section.

Note See the sections “Dynamic Multiple Encapsulations” and “Configuring Encapsulation on ISDN BRI” in the chapter “Configuring ISDN BRI” for information about the Cisco Dynamic Multiple Encapsulations feature.

Configuring PPP Encapsulation

Each ISDN B channel is treated as a serial line and supports HDLC and PPP encapsulation. The default serial encapsulation is HDLC. To configure PPP encapsulation, use the following command in interface configuration mode:

Command

Purpose

Configures PPP encapsulation.

Configuring Encapsulation for Frame Relay or X.25 Networks

If traffic from this ISDN interface crosses a Frame Relay or X.25 network, the appropriate addressing and encapsulation tasks must be completed as required for Frame Relay or X.25 networks.

See the sections “Sending Traffic over Frame Relay, X.25, or LAPB Networks” in the chapter “Configuring Legacy DDR Spokes” for more information about addressing, encapsulation, and other tasks necessary to configure Frame Relay or X.25 networks.

Configuring Encapsulation for Combinet Compatibility

Historically, Combinet devices supported only the Combinet Proprietary Protocol (CPP) for negotiating connections over ISDN B channels. To enable Cisco routers to communicate with those Combinet bridges, the Cisco IOS software supports the CPP encapsulation type.

To enable routers to communicate over ISDN interfaces with Combinet bridges that support only CPP, use the following commands in interface configuration mode:

Command

Purpose

Step 1

Specifies CPP encapsulation.

Step 2

Enables CPP callback acceptance.

Step 3

Enables CPP authentication.

Most Combinet devices support PPP. Cisco routers can communicate over ISDN with these devices by using PPP encapsulation, which supports both routing and fast switching.

Cisco 700 and 800 series routers and bridges (formerly Combinet devices) support only IP, IPX, and bridging. For AppleTalk, Cisco routers automatically perform half-bridging with Combinet devices. For more information about half-bridging, see the section “Configuring PPP Half-Bridging” in the “Configuring Media-Independent PPP and Multilink PPP” chapter in this publication.

Cisco routers can also half-bridge IP and IPX with Combinet devices that support only CPP. To configure this feature, you only need to set up the addressing with the ISDN interface as part of the remote subnet; no additional commands are required.

Configuring Automatic Detection of Encapsulation Type of Incoming Calls

You can enable a serial or ISDN interface to accept calls and dynamically change the encapsulation in effect on the interface when the remote device does not signal the call type. For example, if an ISDN call does not identify the call type in the Lower Layer Compatibility fields and is using an encapsulation that is different from the one configured on the interface, the interface can change its encapsulation type at that time.

This feature enables interoperation with ISDN terminal adapters that use V.120 encapsulation but do not signal V.120 in the call setup message. An ISDN interface that by default answers a call as synchronous serial with PPP encapsulation can change its encapsulation and answer such calls.

Automatic detection is attempted for the first 10 seconds after the link is established or the first 5 packets exchanged over the link, whichever is first.

To enable automatic detection of encapsulation type, use the following command in interface configuration mode:

Command

Purpose

Enables automatic detection of encapsulation type on the specified interface.

You can specify one or more encapsulations to detect. Cisco IOS software currently supports automatic detection of PPP and V.120 encapsulations.

Configuring Network Addressing

When you configure networking, you specify how to reach the remote recipient. To configure network addressing, use the following commands in interface configuration mode:

Command

Purpose

Step 1

]

or

Defines the protocol address of the remote recipient, host name, and dialing string; optionally, provides the ISDN subaddress; sets the dialer speed to 56 or 64 kbps, as needed.

keyword that enables ISDN semipermanent connections.

Step 2

Assigns the interface to a dialer group to control access to the interface.

Step 3

Associates the dialer group number with an access list number.

Step 4

Defines an access list permitting or denying access to specified protocols, sources, or destinations.

Australian networks allow semipermanent connections between customer routers with PRIs and the TS-014 ISDN PRI switches in the exchange. Semipermanent connections are offered at better pricing than leased lines.

command are considered interesting and cause the router to place a call to the identified destination protocol address.

Note The access list reference in Step 4 of this task list is an example of the access list commands allowed by different protocols. Some protocols might require a different command form or might require multiple commands. See the relevant chapter in the appropriate network protocol configuration guide (for example, the Cisco IOS AppleTalk and Novell IPX Configuration Guide) for more information about setting up access lists for a protocol.

For more information about defining outgoing call numbers, see the sections “Configuring Access Control for Outgoing Calls” in the chapters “Configuring Legacy DDR Spokes” or “Configuring Legacy DDR Hubs” later in this publication.

Configuring ISDN Calling Number Identification

A router might need to supply the ISDN network with a billing number for outgoing calls. Some networks offer better pricing on calls in which the number is presented. When configured, the calling number information is included in the outgoing Setup message.

To configure the interface to identify the billing number, use the following command in interface configuration mode:

Command

Purpose

Specifies the calling party number.

This command can be used with all ISDN PRI switch types.

Overriding the Default TEI Value

You can configure ISDN terminal endpoint identifier (TEI) negotiation on individual ISDN interfaces. TEI negotiation is useful for switches that may deactivate Layers 1 or 2 when there are no active calls. Typically, this setting is used for ISDN service offerings in Europe and connections to DMS 100 switches that are designed to initiate TEI negotiation.

. To apply TEI negotiation to a specific PRI interface, use the following command in interface configuration mode:

Command

Purpose

]

Determines when ISDN TEI negotiation occurs.

Configuring a Static TEI

Depending on the telephone company you subscribe to, you may have a dynamically or statically assigned terminal endpoint identifier (TEI) for your ISDN service. By default, TEIs are dynamic in Cisco routers. To configure the TEI as a static configuration, use the following command in interface configuration mode:

Command

Purpose

Configures a static ISDN Layer 2 TEI over the D channel.

Configuring Incoming ISDN Modem Calls

All incoming ISDN analog modem calls that come in on an ISDN PRI receive signaling information from the ISDN D channel. The D channel is used for circuit-switched data calls and analog modem calls.

To enable all incoming ISDN voice calls to access the call switch module and integrated modems, use the following command in interface configuration mode:

Command

Purpose

]}

Routes incoming ISDN modem calls to the call switch module.

interface command determine how a call is handled based on bearer capability information, as follows:

- isdn incoming-voice voice —Calls bypass the modem and are handled as a voice call.

- isdn incoming-voice data —Calls bypass the modem and are handled as digital data.

- isdn incoming-voice modem —Calls are passed to the modem and the call negotiates the appropriate connection with the far-end modem.

interface configuration command to configure incoming ISDN voice and data calls.

Filtering Incoming ISDN Calls

You may find it necessary to configure your network to reject an incoming call with some specific ISDN bearer capability such as nonspeech or nonaudio data. To filter out unwanted call types, use the following command in interface configuration mode:

Command

Purpose

]}}

Rejects an incoming ISDN BRI or PRI call based on type.

Note When the ISDN interface is configured for incoming voice with the isdn incoming-voice voice command (see the previous section “Configuring Incoming ISDN Modem Calls”), and bearer capability indicates the call as unrestricted digital data (i = 0x8890), the call is handled as voice over data (use vod keyword).

Verifying the Call Reject Configuration

To verify that calls are being rejected, perform the following steps:

commands at the privileged EXEC prompt:

- debug isdn event

- debug isdn event detail

- debug isdn q931

- debug isdn q931 l3trace

command. The following example configures the network to reject all incoming data calls on ISDN interfaces 4 through 23:

Device(config)# interface serial 4:23

Device(config-if)# isdn reject data

Device(config-if)# ^Z

command output for the following string, which indicates that the call was rejected:

ISDN <TYPE:NUMBER>: Rejecting call id <CALLID> isdn calltype screening failed

EXEC command to display a detailed report of the ISDN configuration, including status of Layers 1 through 3, the call type, and the call identifier.

, for example.

Configuring the ISDN Guard Timer

Beginning in Cisco IOS Release 12.2, the ISDN guard timer feature implements a new managed timer for ISDN calls. Because response times for authentication requests can vary, for instance when using DNIS authentication, the guard timer allows you to control the handling of calls.

To configure the ISDN guard timer, use the following command in interface configuration mode:

Command

Purpose

Enables the guard timer and sets the number of milliseconds for which the access server waits for RADIUS to respond before rejecting or accepting (optional) a call.

.

Configuring Inclusion of the Sending Complete Information Element

In some geographic locations, such as Hong Kong and Taiwan, ISDN switches require that the Sending Complete information element be included in the outgoing Setup message to indicate that the entire number is included. This information element is generally not required in other locations.

To configure the interface to include the Sending Complete information element in the outgoing call Setup message, use the following command in interface configuration mode:

Command

Purpose

Includes the Sending Complete information element in the outgoing call Setup message.

Configuring ISDN PRI B-Channel Busyout

To allow the busyout of individual ISDN PRI B channels, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Enters interface configuration mode for a D-channel serial interface.

Step 2

Allows the busyout of individual PRI B channels via SNMP.

Configuring NSF Call-by-Call Support

Network-Specific Facilities (NSF) are used to request a particular service from the network or to provide an indication of the service being provided. Call-by-call support means that a B channel can be used for any service; its use is not restricted to a certain preconfigured service, such as incoming 800 calls or an outgoing 800 calls. This specific NSF call-by-call service supports outgoing calls configured as voice calls.

This NSF call-by-call support feature is vendor-specific; only routers connected to AT&T Primary-4ESS switches need to configure this feature. This feature is supported on channelized T1.

To enable the router for NSF call-by-call support and, optionally, to place outgoing voice calls, complete the following steps:

Step 1 Configure the controller for ISDN PRI.

command for each dialing plan to be supported.

Step 3 Define the dialer map class for that dialing plan.

To define the dialer map class for the dialing plan, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

keyword as the class name, and begins map class configuration mode.

Step 2

(Optional) Enables voice calls.

Step 3

Configures the specific dialer map class to make outgoing calls.

Note The AT&T primary-4ess ISDN switch type removes the prefix 011 from the Digital Number Identification Service (DNIS) number during the call setup before sending a call to the PSTN. The removal of 011 is required because the primary-4ess switch type is primarily meant for the United States of America and follows North American Numbering Plan (NANP).

lists the NSF dialing plans and supported services offered on AT&T Primary-4ESS switches.

Table 3 NSF Supported Services on AT&T Primary-4ESS Switches

NSF Dialing Plan

Data

Voice

International

Software Defined Network (SDN)4

Yes

Yes

Global SDN

MEGACOMM

No

Yes

Yes

ACCUNET

Yes

Yes

Yes

4.The dialing plan terminology in this table is defined and used by AT&T.

4.The dialing plan terminology in this table is defined and used by AT&T.

Configuring Multiple ISDN Switch Types

command to the interface level. This allows PRI and BRI to run simultaneously on platforms that support both interface types.

A global ISDN switch type is required and must be configured on the router before you can configure a switch type on an interface.

To configure multiple ISDN switch types for a PRI interface using a channelized E1 or channelized T1 controller, use the following command in global configuration mode:

Command

Purpose

Applies a global ISDN switch type.

lists valid ISDN switch types for BRI and PRI interfaces.

Note When you configure an ISDN switch type on the channelized E1 or T1 controller, this switch type is applied to all time slots on that controller. For example, if you configure channelized T1 controller 1:23, which corresponds to serial interface 1, with the ISDN switch type keyword primary-net5, then all time slots on serial interface 1 (and T1 controller 1) will use the Primary-Net5 switch type.

The following restrictions apply to the Multiple ISDN Switch Types feature:

- You must configure a global ISDN switch type using the existing isdn switch-type global configuration command before you can configure the ISDN switch type on an interface. Because global commands are processed before interface level commands, the command parser will not accept the isdn switch-type command on an interface unless a switch type is first added globally. Using the i sdn switch-type global command allows for backward compatibility.

- If an ISDN switch type is configured globally, but not at the interface level, then the global switch type value is applied to all ISDN interfaces.

- If an ISDN switch type is configured globally and on an interface, the interface level switch type supersedes the global switch type at initial configuration. For example, if the global BRI switch-type keyword basic-net3 is defined and the interface-level BRI switch-type keyword is basic-ni , the National ISDN switch type is the value applied to that BRI interface.

- The ISDN global switch type value is only propagated to the interface level on initial configuration or router reload. If you reconfigure the global ISDN switch type, the new value is not applied to subsequent interfaces. Therefore, if you require a new switch type for a specific interface, you must configure that interface with the desired ISDN switch type.

- If an ISDN global switch type is not compatible with the interface type you are using or you change the global switch type and it is not propagated to the interface level, as a safety mechanism, the router will apply a default value to the interface level, as indicated in Table 4 .

Table 4 ISDN PRI and ISDN BRI Global Switch Type Keywords

Global Switch Type

PRI Interface

BRI Interface

ISDN switch type to any BRI interfaces. You can override the default switch assignment by configuring a different ISDN switch type on the associated interface.

Configuring B Channel Outgoing Call Order

You can configure the router to select the first available B channel in ascending order (channel B1) or descending order (channel B23 for a T1 and channel B30 for an E1). To configure the optional task of selecting B channel order for outgoing calls for PRI interface types, use the following command in interface configuration mode:

Command

Purpose

}

Enables B channel selection for outgoing calls on a PRI interface (optional).

Before configuring the ISDN PRI on your router, check with your service vendor to determine if the ISDN trunk call selection is configured for ascending or descending order. If there is a mismatch between the router and switch with regard to channel availability, the switch will send back an error message stating the channel is not available. By default, the router will select outgoing calls in descending order.

Performing Configuration Self-Tests

commands.

Command

Purpose

Checks Layer 1 (physical layer) of the PRI over T1.

Checks Layer 1 (physical layer) of the PRI over E1.

Checks the status of PRI channels.

Checks Layer 2 (data link layer).

or

or

or

Checks Layer 3 (network layer).

Monitoring and Maintaining ISDN PRI Interfaces

To monitor and maintain ISDN interfaces, use the following EXEC commands as needed:

Command

Purpose

Cisco 7500 series routers

or

Cisco 4000 series routers

Displays information about the physical attributes of the ISDN PRI over T1 B and D channels.

Cisco 7500 series routers

or

Cisco 4000 series routers

Displays information about the physical attributes of the ISDN PRI over E1 B and D channels.

Cisco 7500 series routers

]

or

Cisco 4000 series routers

Displays information about the T1 links supported on the ISDN PRI B and D channels.

Cisco 7500 series routers

]

or

Cisco 4000 series routers

Displays information about the E1 links supported on the ISDN PRI B and D channels.

}

keyword is available for PRI only.)

]

Obtains general diagnostic information about the specified interface.

How to Configure Robbed-Bit Signaling for Analog Calls over T1 Lines

Some Cisco access servers support robbed-bit signaling for receiving and sending analog calls on T1 lines. Robbed-bit signaling emulates older analog trunk and line in-band signaling methods that are sent in many networks.

In countries that support T1 framing (such as the United States and Canada), many networks send supervisory and signaling information to each other by removing the 8th bit of each time slot of the 6th and 12th frame for superframe (SF) framing. For networks supporting extended superframe (ESF) framing, the 6th, 12th, 18th, and 24th frames are affected. This additional signaling information is added to support channel banks in the network that convert various battery and ground operations on analog lines into signaling bits.

Robbed-bit signaling configured on a Cisco access server enables integrated modems to answer and send analog calls. Robbed bits are forwarded over digital lines. To support analog signaling over T1 lines, robbed-bit signaling must be enabled.

Note The signal type configured on the access server must match the signal type offered by your telco provider. Ask your telco provider which signal type to configure on each T1 controller.

The Cisco access server has two controllers: controller T1 1 and controller T1 0, which must be configured individually.

To configure robbed-bit signaling support for calls made and received, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Enables the T1 0 controller and begins controller configuration mode.

Step 2

If the channelized T1 line connects to a smart jack instead of a CSU, sets pulse equalization (use parameter values specified by your telco service provider).

Step 3

.

Step 4

Step 5

Configures one T1 line to serve as the primary or most stable clock source line.

Step 6

Configures channels to accept voice calls.

This step creates interfaces that you can configure.

Step 7

}

Sets the facilities data-link exchange standard for the CSU, as specified by your telco service provider.

If you want to configure robbed-bit signaling on the other T1 controller, repeat Steps 1 through 7, making sure in Step 5 to select T1 controller line 1 as the secondary clock source.

If you want to configure ISDN on the other controller, see the section “How to Configure ISDN PRI” in this chapter. If you want to configure channel groupings on the other controller, see the chapter “Configuring Synchronous Serial Ports” in this publication; specify the channel groupings when you specify the interface.

See the section “Robbed-Bit Signaling Examples” at the end of this chapter for configuration examples.

How to Configure CAS

The following sections describe how to configure channel-associated signaling in Cisco networking devices for both channelized E1 and T1 lines:

- CAS on Channelized E1

- CAS on T1 Voice Channels

CAS on Channelized E1

Cisco access servers and access routers support CAS for channelized E1 lines, which are commonly deployed in networks in Latin America, Asia, and Europe. CAS is configured to support channel banks in the network that convert various battery and ground operations on analog lines into signaling bits, which are forwarded over digital lines.

CAS is call signaling that is configured on an E1 controller and enables the access server to send or receive analog calls. The signaling uses the16th channel (time slot); thus, CAS fits in the out-of-band signaling category.

Once CAS is configured on a single E1 controller, remote users can simultaneously dial in to the Cisco device through networks running the R2 protocol (see specifications for your particular network device for the number of dialins supported).

The R2 protocol is an international signaling standard for analog connections. Because R2 signaling is not supported in the Cisco access servers, an E1-to-E1 converter is required.

Figure 1 illustrates that, because the Cisco access servers have more than one physical E1 port on the dual E1 PRI board, up to 60 simultaneous connections can be made through one dual E1 PRI board.

Figure 1 Remote PC Accessing Network Resources Through the Cisco AS5000 Series Access Server

Note For information on how to configure an Anadigicom E1-to-E1 converter, see to the documentation that came with the converter.

Note The dual E1 PRI card must be installed in the Cisco access server before you can configure CAS. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information.

Configuring CAS for Analog Calls over E1 Lines

To configure the E1 controllers in the Cisco access servers, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

argument are 1 or 2) and begins controller configuration mode.

Step 2

Configures CAS and the R2 signaling protocol on a specified number of time slots.

Step 3

Defines the framing characteristics as CRC4.

Step 4

Defines the line code as HDB3.

Step 5

5

Specifies one E1 line to serve as the primary or most stable clock source line.

5.Specify the other E1 line as the secondary clock source using the clock source line secondary command.

5.Specify the other E1 line as the secondary clock source using the clock source line secondary command.

If you do not specify the time slots, CAS is configured on all 30 B channels and one D channel on the specified controller.

See the section “ISDN CAS Examples” for configuration examples.

Configuring CAS on a Cisco Router Connected to a PBX or PSTN

To define E1 channels for the CAS method by which the router connects to a PBX or PSTN, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Device(config)# controller e1 slot / port

Specifies the E1 controller that you want to configure with R2 signaling and begins controller configuration.

Step 2

Device(config-controller)# ds0-group ds0-group-no timeslots timeslot-list type { e&m-immediate | e&m-delay | e&m-wink | fxs-ground-start | fxs-loop-start | fxo-ground-start | fxo-loop-start }

Configures channel-associated signaling and the signaling protocol on a specified number of time slots.

Step 3

Device(config-controller)# framing crc4

Defines the framing characteristics as cyclic redundancy check 4 (CRC4).

Step 4

Device(config-controller)# linecode hdb3

Defines the line code as high-density bipolar 3 (HDB3).

Step 5

Device(config-controller)# clock source line primary 6

Specifies one E1 line to serve as the primary or most stable clock source line.

6.Specify the other E1 line as the secondary clock source using the clock source line secondary command.

6.Specify the other E1 line as the secondary clock source using the clock source line secondary command.

If you do not specify the time slots, channel-associated signaling is configured on all 30 B channels and one D channel on the specified controller.

CAS on T1 Voice Channels

Various types of CAS signaling are available in the T1 world. The most common forms of CAS signaling are loop-start, ground-start, and recEive and transMit (E&M). The biggest disadvantage of CAS signaling is its use of user bandwidth to perform signaling functions. CAS signaling is often referred to as robbed-bit-signaling because user bandwidth is being “robbed” by the network for other purposes. In addition to receiving and placing calls, CAS signaling also processes the receipt of DNIS and ANI information, which is used to support authentication and other functions.

This configuration allows the Cisco access servers to provide the automatic number identification/dialed number identification service (ANI/DNIS) delimiter on incoming T1/CAS trunk lines. The digit collection logic in the call switching module (CSM) for incoming T1 CAS calls in dual tone multifrequency (DTMF) is modified to process the delimiters, the ANI digits, and the DNIS digits.

As part of the configuration, a CAS signaling class with the template to process ANI/DNIS delimiters has to be defined. This creates a signaling class structure which can be referred to by its name.

This feature is only functional in a T1 CAS configured for E&M-feature group b (wink start). E&M signaling is typically used for trunks. It is normally the only way that a central office (CO) switch can provide two-way dialing with direct inward dialing. In all the E&M protocols, off-hook is indicated by A=B=1, and on-hook is indicated by A=B=0. If dial pulse dialing is used, the A and B bits are pulsed to indicate the addressing digits.

For this feature, here is an example of configuring for E&M-feature group b:

ds0-group 1 timeslots 1-24 type e&m-fgb dtmf dnis

In the original Wink Start protocol, the terminating side responds to an off-hook from the originating side with a short wink (transition from on-hook to off-hook and back again). This wink tells the originating side that the terminating side is ready to receive addressing digits. After receiving addressing digits, the terminating side then goes off-hook for the duration of the call. The originating endpoint maintains off-hook for the duration of the call.

Configuring ANI/DNIS Delimiters for CAS Calls on CT1

To configure the signaling class and ANI/DNIS delimiters, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Device(config)# signaling-class cas name

Names the signaling class and begins interface configuration mode.

Step 2

Device(config-if)# profile incoming template

Defines the template to process the ANI/DNIS delimiter.

Step 3

Device(config-if)# exit

Return to global configuration mode.

Step 4

Device(config)# controller t1 slot / port / number

Enables this feature for a T1 controller and begins controller configuration mode.

Step 5

Device(config-controller)# cas-custom channel

Specifies a single channel group number.

Step 6

Device(config-ctrl-cas)# class name

Enables the ANI/DNIS delimiter feature by specifying the template.

under the cas-custom configuration.

. When removing a signaling class, make sure the signaling class is no longer used by any controllers; otherwise, the following warning will be displayed:

% Can’t delete, signaling class test is being used

How to Configure Switched 56K Digital Dial-In over Channelized T1 and Robbed-Bit Signaling

Internet service providers (ISPs) can provide switched 56-kbps access to their customers using a Cisco AS5000 series access server. Switched 56K digital dial-in enables many services for ISPs. When using traditional ISDN PRI, the access server uses the bearer capability to determine the type of service. However when providing switched 56K over a CT1 RBS connection, the digital signal level 0 (DS0s) in the access server can be configured to provide either modem or 56-kbps data service. The dial-in user can access a 56-kbps data connection using either an ISDN BRI connection or a 2- or 4-wire switched 56-kbps connection. The telco to which the access server connects must configure its switches to route 56-kbps data calls and voice (modem) calls to the appropriate DS0.

Likewise, an enterprise can provide switched 56-kbps digital dial-in services to its full time telecommuters or small remote offices using ISDN PRI or a CT1 RBS connection.

Switched 56K digital dial-in offers the following benefits:

- Enables ISDN BRI clients to connect to a Cisco access server over switched 56K and T1 CAS.

- Provides switched 56K dial-in services over T1 CAS to remote clients that do not have access to ISDN BRI, for example, a remote PC making digital calls over a 2- or 4-wire switched 56-kbps connection and a CSU.

The following prerequisites apply to the Switched 56K Digital Dial-In feature:

- The remote device could be an ISDN BRI end point such as a terminal adapter or BRI router. In this scenario, the CSU/DSU is irrelevant. For 2- or 4-wire switched 56K remote clients, the remote endpoint must be compatible with the service of the carrier. Different carriers may implement different versions of switched 56K end points.

- A CSU/DSU must be present at the remote client side of the connection. Otherwise, switched 56K connections are not possible. The Cisco access servers have built-in CSU/DSUs.

- The telco must configure its side of the T1 connection to deliver 56-kbps data calls to the correct range of DS0s. If you do not want to dedicate all the DS0s or time slots on a single T1 to switched 56K services, be sure to negotiate with the telco about which DS0s will support switched 56K and which DS0s will not.

- Cisco IOS Release 11.3(2)T or later must be running on the access server.

The following restrictions apply to Switched 56K digital dial-in:

- A Cisco access server only supports incoming switched 56K calls. Dialing out with switched 56K is not supported at this time.

- Switched 56K over E1 is not supported. Only switched 56K over T1 is supported.

- Analog modem calls are not supported over DS0s that are provisioned for switched 56K. For a configuration example, see the section “Switched 56K and Analog Modem Calls over Separate T1 CAS Lines Example” later in this chapter.

- Certain types of T1 lines, such as loop start and ground start, might not support this service. Contact your telco vendor to determine if this feature is available.

Switched 56K Scenarios

The following scenarios are provided to show multiple applications for supporting switched 56K over T1 CAS:

- Switched 56K and Analog Modem Calls into T1 CAS

- Basic Call Processing Components

- ISDN BRI Calls into T1 CAS

Switched 56K and Analog Modem Calls into T1 CAS

Figure 2 shows a sample network scenario using switched 56K. Two remote PCs are dialing in to the same Cisco access server to get access to the Internet. The desktop PC is making switched 56K digital calls through an external CSU/DSU. The laptop PC is making analog modem calls through a 28.8-kbps modem. The Cisco access server dynamically assigns IP addresses to each node and forwards data packets off to the switched 56K channels and onboard modems respectively.

Figure 2 PCs Making Switched 56K and Analog Modem Calls into a Cisco AS5000 Series Access Server

For the startup running configuration on the Cisco access server shown in Figure 2, see the section “Comprehensive Switched 56K Startup Configuration Example” later in this chapter.

Basic Call Processing Components

Figure 3 shows the basic components that process switched 56K calls and analog modem calls on board a Cisco access server. Switched 56K and modem calls are signaling using robbed-bit signaling. Digital switched 56K calls utilize logical serial interfaces just like in ISDN PRI. Modem calls utilize asynchronous interfaces, lines, and modems.

Note The BRI terminal must originate its calls with a bearer capability of 56 kbps.

Figure 3 Processing Components for Switched 56K Calls Versus Analog Modem Calls

Note The Cisco IOS software does enable you to configure one T1 controller to support both switched 56K digital calls and analog modem calls. In this scenario, Figure 3 would show all calls coming into the access server through one T1 line and controller. However, you must negotiate with the telco which DS0s will support switched 56K services and which DS0s will not. On the access server, analog modem calls are not supported over DS0s that are provisioned for switched 56K. For an example software configuration, see the section “Mixture of Switched 56K and Modem Calls over CT1 CAS Example” at the end of this chapter.

ISDN BRI Calls into T1 CAS

Figure 4 shows how switched 56K functionality can be used to forward ISDN BRI network traffic to a Cisco access server that is configured for switched 56K robbed-bit signaling over CT1.

Note The BRI terminal must originate its calls with a bearer capability of 56 kbps.

Figure 4 Remote PC Making BRI Digital Calls via Switched 56K to a Cisco AS5000 Series Access Server

For a configuration example on the Cisco access server, see the section “Comprehensive Switched 56K Startup Configuration Example” at the end of this chapter.

How to Configure Switched 56K Services

command is enabled for switched 56K services, a logical serial interface is automatically created for each 56K channel, which must also be configured.

To configure an access server to support switched 56K digital calls, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Specifies a T1 controller and begins controller configuration mode.

Step 2

}

Sets the framing.

Step 3

}

Defines the line code.

Step 4

}

Specifies the clocking.

Step 5

Configures robbed-bit signaling for a range of time slots. A logical serial interface is automatically created for each switched 56K channel.

Step 6

Exits controller configuration mode.

Step 7

command was issued, and configures the core protocol characteristics for the serial interface.

For configuration examples, see the section “Switched 56K Configuration Examples” later in this chapter.

How to Configure E1 R2 Signaling

R2 signaling is an international signaling standard that is common to channelized E1 networks. However, there is no single signaling standard for R2. The International Telecommunication Union Telecommunication Standardization Sector (ITU-T) Q.400-Q.490 recommendation defines R2, but a number of countries and geographic regions implement R2 in entirely different ways. Cisco addresses this challenge by supporting many localized implementations of R2 signaling in its Cisco IOS software.

The following sections offer pertinent information about the E1 R2 signaling feature:

- E1 R2 Signaling Overview

- Configuring E1 R2 Signaling

- Configuring E1 R2 Signaling for Voice

- Monitoring E1 R2 Signaling

- Verifying E1 R2 Signaling

- Troubleshooting E1 R2 Signaling

E1 R2 Signaling Overview

command for Cisco routers.

command.

Cisco also supports specific local variants of E1 R2 signaling in the following regions, countries, and corporations:

- Argentina

- Laos1

- Australia

- Malaysia

- Bolivia7

- Malta1

- Brazil

- New Zealand

- Bulgaria1

- Paraguay

- China

- Peru

- Colombia

- Philippines

- Costa Rica

- Saudi Arabia

- East Europe8

- Singapore

- Ecuador ITU

- South Africa (Panaftel variant)

- Ecuador LME

- Telmex corporation (Mexico)

- Greece

- Telnor corporation (Mexico)

- Guatemala

- Thailand

- Hong Kong (uses the China variant)

- Uruguay

- Indonesia

- Venezuela

- Israel

- Vietnam

- Korea

7.Cisco 3620 and 3640 series routers only.

7.Cisco 3620 and 3640 series routers only.

8.Includes Croatia, Russia, and Slovak Republic.

8.Includes Croatia, Russia, and Slovak Republic.

Note Only MICA technologies modems support R2 functionality. Microcom modems do not support R2.

The following are benefits of E1 R2 signaling:

- R2 custom localization—R2 signaling is supported for a wide range of countries and geographical regions. Cisco is continually supporting new countries.

- Broader deployment of dial access services—The flexibility of a high-density access server can be deployed in E1 networks.

option does not disable DNIS collection. DNIS is the number being called. ANI is the number of the caller. For example, if you are configuring router A to call router B, then the DNIS number is assigned to router B, the ANI number is assigned to router A. ANI is similar to Caller ID.

Figure 5 shows a sample network topology for using E1 R2 signaling with a Cisco AS5800. All four controllers on the access server are configured with R2 digital signaling. Additionally, localized R2 country settings are enabled on the access server.

Figure 5 Service Provider Using E1 R2 Signaling and a Cisco AS5800

Figure 6 shows a sample network topology for using E1 R2 signaling for voice transfers with a Cisco 2600, 3600, or 7200 series router. All the controllers on the router are configured with R2 digital signaling. Additionally, localized R2 country settings are enabled on the router.

Figure 6 E1 R2 Connections for the Cisco 2600/3600/7200 Series Routers

Configuration examples are supplied in the “Configuration Examples for Channelized E1 and Channelized T1” section at the end of this chapter.

Configuring E1 R2 Signaling

To configure support for E1 R2 signaling on the Cisco access servers, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Specifies the E1 controller that you want to configure with R2 signaling and begins controller configuration mode.

Step 2

argument with any of the following choices under R2 analog, R2 digital, or R2 pulse:

]]

or

]]

or

]]

command.

command.

For an E1 R2 configuration example, see the section “E1 R2 Signaling Procedure.”

Configuring E1 R2 Signaling for Voice

To configure E1 R2 signaling on systems that will be configured for voice, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Device(config)# controller E1 slot / port

Specifies the E1 controller that you want to configure with R2 signaling and begins controller configuration mode.

Step 2

Device(config-controller)# ds0-group channel timeslots range type signal

r2-analog [ dtmf | r2-compelled [ ani ] | r2-non-compelled [ ani ] | r2-semi-compelled [ ani ]]

r2-digital [ dtmf | r2-compelled [ ani ] | r2-non-compelled [ ani ] | r2-semi-compelled [ ani ]]

r2-pulse [ dtmf | r2-compelled [ ani ] | r2-non-compelled [ ani ] | r2-semi-compelled [ ani ]]

command reference page.

Step 3

Enters cas-custom mode. In this mode, you can localize E1 R2 signaling parameters, such as specific R2 country settings for Hong Kong.

command.

Step 4

variable with one of the supported country names.

option, which engages the default settings for a specific country. The default setting for all countries is ITU.

command reference page for the list of supported countries, regions, and corporation specifications.

Step 5

- Device(config-ctrl-cas)# ani-digits

- Device(config-ctrl-cas)# answer-signal

- Device(config-ctrl-cas)# caller-digits

- Device(config-ctrl-cas)# category

- Device(config-ctrl-cas)# default

- Device(config-ctrl-cas)# dnis-digits

- Device(config-ctrl-cas)# invert-abcd

- Device(config-ctrl-cas)# ka

- Device(config-ctrl-cas)# kd

- Device(config-ctrl-cas)# metering

- Device(config-ctrl-cas)# nc-congestion

- Device(config-ctrl-cas)# unused-abcd

- Device(config-ctrl-cas)# request-category

(Optional) Further customizes the R2 signaling parameters. Some switch types require you to fine tune your R2 settings. Do not tamper with these commands unless you fully understand your switch’s requirements.

command fully configures your country’s local settings. You should not need to perform Step 5.

command reference page for more information about each signaling command.

Monitoring E1 R2 Signaling

To monitor E1 R2 signaling, use the following commands in EXEC mode as needed:

Command

Purpose

Device> show controllers e1

or

Device> show controllers e1 number

Displays the status for all controllers or a specific controller. Be sure the status indicates the controller is up and there are no alarms or errors (lines 2, 4, 9, and 10, as shown immediately below in the “Monitoring E1 R2 Using the show controllers e1 Command” section).

Device> show modem csm [ slot / port | group number ]

Displays status for a specific modem, as shown below in the “Monitoring E1 R2 Signaling Using the show modem csm Command” section.

Monitoring E1 R2 Using the show controllers e1 Command

Device# show controllers e1 0

E1 0 is up.

Applique type is Channelized E1 - balanced

No alarms detected.

Version info of Slot 0: HW: 2, Firmware: 4, PLD Rev: 2

Manufacture Cookie is not programmed.

Framing is CRC4, Line Code is HDB3, Clock Source is Line Primary.

Data in current interval (785 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 13 15 minute intervals):

0 Line Code Violations, 0 Path Code Violations,

0 Slip Secs, 12 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,

0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 12 Unavail Secs

Monitoring E1 R2 Signaling Using the show modem csm Command

Device# show modem csm 1/0

MODEM_INFO: slot 1, port 0, unit 0, tone r2-compelled, modem_mask=0x0000, modem_port_offset=0

tty_hwidb=0x60E63E4C, modem_tty=0x60C16F04, oobp_info=0x00000000, modem_pool=0x60BC60CC

modem_status(0x0002): VDEV_STATUS_ACTIVE_CALL.

csm_state(0x0205)=CSM_IC5_CONNECTED, csm_event_proc=0x600CFF70, current call thru CAS line

invalid_event_count=0, wdt_timeout_count=0

wdt_timestamp_started is not activated

wait_for_dialing:False, wait_for_bchan:False

pri_chnl=TDM_PRI_STREAM(s0, u3, c7), modem_chnl=TDM_MODEM_STREAM(s1, c0)

dchan_idb_start_index=0, dchan_idb_index=0, call_id=0x0239, bchan_num=6

csm_event=CSM_EVENT_DSX0_CONNECTED, cause=0x0000

ring_no_answer=0, ic_failure=0, ic_complete=3

dial_failure=0, oc_failure=0, oc_complete=0

oc_busy=0, oc_no_dial_tone=0, oc_dial_timeout=0

remote_link_disc=2, stat_busyout=2, stat_modem_reset=0

oobp_failure=0

call_duration_started=00:04:56, call_duration_ended=00:00:00, total_call_duration=00:01:43

The calling party phone number =

The called party phone number = 9993003

total_free_rbs_timeslot = 0, total_busy_rbs_timeslot = 0, total_dynamic_busy_rbs_timeslot = 0, total_static_busy_rbs_timeslot = 0, min_free_modem_threshold = 0

Verifying E1 R2 Signaling

command to view the status for a particular controller. Make sure that the status indicates that the controller is up (line 2 in the following example) and that no alarms (line 6 in the following example) or errors (lines 9, 10, and 11 in the following example) have been reported.

Device# show controller E1 1/0

E1 1/0 is up.

Applique type is Channelized E1

Cablelength is short 133

Description: E1 WIC card Alpha

No alarms detected.

Framing is CRC4, Line Code is HDB3, Clock Source is Line Primary.

Data in current interval (1 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

Troubleshooting E1 R2 Signaling

If a connection does not come up, check for the following:

- Loose wires, splices, connectors, shorts, bridge taps, and grounds

- Backward send and receive

- Mismatched framing types (for example, CRC-4 versus no CRC-4)

- Send and receive pair separation (crosstalk)

- Faulty line cards or repeaters

- Noisy lines (for example, power and crosstalk)

If you see errors on the line or the line is going up and down, check the following:

- Mismatched line codes (HDB3 versus AMI)

- Receive level

- Frame slips due to poor clocking plan

command, as shown immediately below in the “Debug E1 R1 Signaling Using the debug modem Command” section.

Debug E1 R1 Signaling Using the debug modem Command

Device# debug modem csm 1/0

*May 15 04:05:46.675: VDEV_ALLOCATE: slot 2 and port 39 is allocated.

*May 15 04:05:46.675: CSM_RX_CAS_EVENT_FROM_NEAT:(04BF): EVENT_CALL_DIAL_IN at slot 2 and port 39

*May 15 04:05:46.675: CSM_PROC_IDLE: CSM_EVENT_DSX0_CALL at slot 2, port 39

*May 15 04:05:46.675: Mica Modem(2/39): Configure(0x0)

*May 15 04:05:46.675: Mica Modem(2/39): Configure(0x3)

*May 15 04:05:46.675: Mica Modem(2/39): Configure(0x6)

*May 15 04:05:46.675: Mica Modem(2/39): Call Setup

*May 15 04:05:46.891: Mica Modem(2/39): State Transition to Call Setup

*May 15 04:05:46.891: Mica Modem(2/39): Went offhook

*May 15 04:05:46.891: CSM_PROC_IC1_RING: CSM_EVENT_MODEM_OFFHOOK at slot 2, port 39

When the E1 controller comes up, you will see the following messages:

%CONTROLLER-3-UPDOWN: Controller E1 0, changed state to up

It also shows these messages for individual timeslots:

%DSX0-5-RBSLINEUP: RBS of controller 1 timeslot 1 is up

%DSX0-5-RBSLINEUP: RBS of controller 1 timeslot 2 is up

%DSX0-5-RBSLINEUP: RBS of controller 1 timeslot 3 is up

%DSX0-5-RBSLINEUP: RBS of controller 1 timeslot 4 is up

%DSX0-5-RBSLINEUP: RBS of controller 1 timeslot 5 is up

%DSX0-5-RBSLINEUP: RBS of controller 1 timeslot 6 is up

%DSX0-5-RBSLINEUP: RBS of controller 1 timeslot 7 is up

%DSX0-5-RBSLINEUP: RBS of controller 1 timeslot 8 is up

Enabling R1 Modified Signaling in Taiwan

Enabling R1 modified signaling allows a Cisco universal access server to communicate with central office trunks that also use R1 modified signaling. R1 modified signaling is an international signaling standard that is common to channelized T1/E1 networks. Cisco IOS Release 12.1 supports R1 modified signaling customized for Taiwan only. You can configure a channelized T1/E1 interface to support different types of R1 modified signaling, which is used in older analog telephone networks.

This feature allows enterprises and service providers to fully interoperate with the installed Taiwanese telecommunications standards, providing interoperability in addition to the vast array of Cisco IOS troubleshooting and diagnostic capability. This feature will provide customers with a seamless, single-box solution for their Taiwan signaling requirements.

Note This type of signaling is not the same as ITU R1 signaling; it is R1 signaling modified for Taiwan specifically. In the future, R1 modified signaling will be supported by the Cisco AS5800 access server, and will also be available in Turkey.

The following restrictions are for the use of R1 modified signaling:

- Because different line signaling uses different A/B/C/D bit definitions to represent the line state, you must understand the configuration of the T1/E1 trunk before configuring the CAS group. If the wrong type of provision is configured, the access server might interpret the wrong A/B/C/D bit definitions and behave erratically.

- Cisco access servers (Cisco AS5300, and Cisco AS5800) with Microcom modems cannot support this feature.

- You must know the configuration of the T1/E1 trunk before configuring the cas-group. If there is a trunk provisioning mismatch, performance problems may occur.

R1 Modified Signaling Topology

Figure 7 illustrates a service provider using R1 signaling with E1 and a Cisco AS5200 access server. The network topology would be the same for T1 or a Cisco AS5300 access server.

Figure 7 Service Provider Using E1 R1 Signaling with a Cisco AS5200 Access Server

Figure 8 illustrates a service provider using R1 modified signaling with E1 and a Cisco AS5800 access server.

Figure 8 Service Provider Using E1 R1 Modified Signaling with a Cisco AS5800 Access Server

R1 Modified Signaling Configuration Task List

This section describes how to enable R1 modified signaling on your Cisco access server on both a T1 and E1 interface.

Before beginning the tasks in this section, check for the following hardware and software in your system:

- Cisco AS 5200, Cisco AS5300, or Cisco AS5800 access server (without a Microcom modem)

- Cisco IOS Release 12.1 or later software

- MICA feature module

- Portware Version 2.3.1.0 or later

For information on upgrading your Cisco IOS images, modem portware, or modem code, go to the following locations and then select your access server type (Cisco AS5200, Cisco AS5300, or Cisco AS5800) and port information:

- On Cisco.com:

http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/

Cisco Product Documentation/Access Servers and Access Routers/Access Servers

- On the Documentation CD-ROM:

Cisco Product Documentation/Access Servers and Access Routers/Access Servers

To configure R1 modified signaling, perform the tasks in the following sections, as required:

- Configuring R1 Modified Signaling on a T1 Interface

- Configuring R1 Modified Signaling on an E1 Interface

Note The sample prompts and output are similar for the Cisco AS5200, Cisco AS5300 and Cisco AS5800 access servers.

Configuring R1 Modified Signaling on a T1 Interface

To configure R1 modified signaling on a T1 interface, use the following commands beginning global configuration mode:

Command

Purpose

Step 1

Cisco AS5800 access server

or

Cisco AS5200 and AS5300 access servers

]

for port details.

The T1 controller ports are labeled 0 to 3 on the quad T1/PRI cards in the Cisco AS5200 and AS5300 access servers.

Step 2

}

.

configures framing to T1 only.

Step 3

}

configures line code to AMI9 encoding.

encoding.

Step 4

]}

configures the clock source to the internal clock.

configures the clock source to the primary recovered clock.

configures the clock source to the secondary recovered clock.

Step 5

}}

Configures the time slots that belong to each E1 circuit for r1-modified or for r1-itu signaling.10

- The cas-group # ranges from 0 to 23 for CT1.

- The timeslot # ranges from 1 to 24 for CT1.

- For the type , each CAS group can be configured as one of the Robbed Bit Signaling provisions.

- ani-dnis indicates R1 will collect ani and dnis information; dnis indicates R1 will collect only dnis information.

Step 6

key. (This message returned is expected and does not indicate an error.)

9.AMI = alternate mark inversion.

9.AMI = alternate mark inversion.

10.For a more detailed description of the syntax and arguments of this command, refer to the Cisco IOS Dial Technologies Command Reference.

10.For a more detailed description of the syntax and arguments of this command, refer to the Cisco IOS Dial Technologies Command Reference.

Configuring R1 Modified Signaling on an E1 Interface

To configure R1 modified signaling on an E1 interface, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Cisco AS5800 access server

or

Cisco AS5200 and AS5300 access servers

]

Specifies the T1 controller that you want to configure and begins controller configuration mode.

for port details.

The T1 controller ports are labeled 0 to 3 on the quad T1/PRI cards in the Cisco AS5200 and AS5300 access servers.

Step 2

configures framing to E1 with CRC.11

configures framing to E1 only.

Step 3

}

configures line code to AMI12 encoding.

configures line code to HDB13 encoding.

Step 4

]}

configures the clock source to the internal clock.

configures the clock source to the primary recovered clock.

configures the clock source to the secondary recovered clock.

Step 5

}

Configures the time slots that belong to each E1 circuit for R1 modified signaling.14

- The cas-group number ranges from 0 to 30 for CE1.

- The timeslot number ranges from 1 to 31 for CE1.

- For the type , each CAS group can be configured as one of the robbed bit signaling provisions.

- ani-dnis indicates R1 will collect ANI and DNIS information; dnis indicates R1 will collect only DNIS information.

Step 6

Device(config-controller-cas)# cas-custom 1

(Optional) Enters the channel number to customize.

Step 7

This message is normal and does not indicate an error.

11.CRC = cyclic redundancy check.

11.CRC = cyclic redundancy check.

12.AMI = alternate mark inversion.

12.AMI = alternate mark inversion.

13.HDB = high-density bipolar 3.

13.HDB = high-density bipolar 3.

14.For a more detailed description of the syntax and arguments of this command, refer to the Cisco IOS Dial Technologies Command Reference.

14.For a more detailed description of the syntax and arguments of this command, refer to the Cisco IOS Dial Technologies Command Reference.

Troubleshooting Channelized E1 and T1 Channel Groups

Each channelized T1 or channelized E1 channel group is treated as a separate serial interface. To troubleshoot channel groups, first verify configurations and check everything that is normally checked for serial interfaces. You can verify that the time slots and speed are correct for the channel group by checking for CRC errors and aborts on the incoming line.

Note None of the Cisco channelized interfaces will react to any loop codes. To loop a channelized interface requires that the configuration command be entered manually.

Two loopbacks are available for channel groups and are described in the following sections:

- Interface Local Loopback

- Interface Remote Loopback

Interface Local Loopback

Interface local loopback is a bidirectional loopback, which will loopback toward the router and toward the line. The entire set of time slots for the channel group is looped back. The service provider can use a BERT test set to test the link from the central office to your local router, or the remote router can test using pings to its local interface (which will go from the remote site, looped back at your local site, and return to the interface on the remote site).

To place the serial interface (channel group) into local loopback, use the following command in interface configuration mode:

Command

Purpose

Places the serial interface (channel group) in local loopback.

Interface Remote Loopback

Remote loopback is the ability to put the remote DDS CSU/DSU in loopback. It will work only with channel groups that have a single DS0 (1 time slot), and with equipment that works with a latched CSU loopback as specified in AT&T specification TR-TSY-000476, “OTGR Network Maintenance Access and Testing.” To place the serial interface (channel group) in remote loopback, use the following command in interface configuration mode:

Command

Purpose

Places the serial interface (channel group) in remote loopback.

interface command sends a latched CSU loopback command to the remote CSU/DSU. The router must detect the response code, at which time the remote loopback is verified.

Configuration Examples for Channelized E1 and Channelized T1

- ISDN PRI Examples

- PRI Groups and Channel Groups on the Same Channelized T1 Controller Example

- Robbed-Bit Signaling Examples

- Switched 56K Configuration Examples

- ISDN CAS Examples

- E1 R2 Signaling Procedure

- R1 Modified Signaling Using an E1 Interface Example

- R1 Modified Signaling for Taiwan Configuration Example

ISDN PRI Examples

This section contains the following ISDN PRI examples:

- Global ISDN, BRI, and PRI Switch Example

- Global ISDN and Multiple BRI and PRI Switch Using TEI Negotiation Example

- NSF Call-by-Call Support Example

- PRI on a Cisco AS5000 Series Access Server Example

- ISDN B-Channel Busyout Example

- Multiple ISDN Switch Types Example

- Outgoing B-Channel Ascending Call Order Example

- Static TEI Configuration Example

- Call Reject Configuration Examples

- ISDN Cause Code Override and Guard Timer Example

Global ISDN, BRI, and PRI Switch Example

keyword) that will override the National ISDN switch type configured globally. The PRI interface (channelized T1 controller) is configured for ISDN switch type Primary-Net5 and is applied only to the PRI.

Global ISDN and Multiple BRI and PRI Switch Using TEI Negotiation Example

).

isdn switch-type basic-net

!

interface serial0:23

isdn switch-type primary-net5

ip address 172.21.24.85 255.255.255.0

!

interface BRI0

isdn switch-type basic-ni

isdn tei first-call

NSF Call-by-Call Support Example

.

commands, that are needed to configure the ISDN interface to make outgoing calls.

! The following lines configure the channelized T1 controller; all time slots are

! configured for ISDN PRI.

!

controller t1 1/1

framing esf

linecode b8zs

pri-group timeslots 1-23

isdn switchtype primary-4ess

!

! The following lines configure the D channel for DDR. This configuration applies

! to all B channels on the ISDN PRI interface.

interface serial 1/1:23

description Will mark outgoing calls from AT&T type calls.

ip address 10.1.1.1 255.255.255.0

encapsulation ppp

dialer map ip 10.1.1.2 name tommyjohn class sdnplan 14193460913

dialer map ip 10.1.1.3 name angus class megaplan 14182616900

dialer map ip 10.1.1.4 name angus class accuplan 14193453730

dialer-group 1

ppp authentication chap

map-class dialer sdnplan

dialer outgoing sdn

map-class dialer megaplan

dialer voice-call

dialer outgoing mega

map-class dialer accuplan

dialer outgoing accu

PRI on a Cisco AS5000 Series Access Server Example

The following example configures ISDN PRI on the appropriate interfaces for IP dial-in on channelized T1:

! T1 PRI controller configuration

controller T1 0

framing esf

linecode b8zs

clock source line primary

pri-group timeslots 1-24

!

controller T1 1

framing esf

linecode b8zs

clock source line secondary

pri-group timeslots 1-24

!

interface Serial0:23

isdn incoming-voice modem

dialer rotary-group 1

!

interface Serial1:23

isdn incoming-voice modem

dialer rotary-group 1

!

interface Loopback0

ip address 172.16.254.254 255.255.255.0

!

interface Ethernet0

ip address 172.16.1.1 255.255.255.0

!

interface Group-Async1

ip unnumbered Loopback0

ip tcp header-compression passive

encapsulation ppp

async mode interactive

peer default ip address pool default

dialer-group 1

ppp authentication chap pap default

group-range 1 48

!

interface Dialer1

ip unnumbered Loopback0

encapsulation ppp

peer default ip address pool default

ip local pool default 172.16.254.1 172.16.254.48

dialer in-band

dialer-group 1

dialer idle-timeout 3600

ppp multilink

ppp authentication chap pap default

The following example configures ISDN PRI on the appropriate interfaces for IP dial-in on channelized E1:

! E1 PRI controller configuration

controller E1 0

framing crc4

linecode hdb3

clock source line primary

pri-group timeslots 1-31

!

controller E1 1

framing crc4

linecode hdb3

clock source line secondary

pri-group timeslots 1-31

interface serial0:15

isdn incoming-voice modem

dialer rotary-group 1

!

interface serial1:15

isdn incoming-voice modem

dialer rotary-group 1

!

interface loopback0

ip address 172.16.254.254 255.255.255.0

!

interface ethernet0

ip address 172.16.1.1 255.255.255.0

!

! The following block of commands configures DDR for all the ISDN PRI interfaces

! configured above. The dialer-group and dialer rotary-group commands tie the

! interface configuration blocks to the DDR configuration.

!

interface dialer1

ip unnumbered loopback0

encapsulation ppp

peer default ip address pool default

ip local pool default 172.16.254.1 172.16.254.60

dialer in-band

dialer-group 1

dialer idle-timeout 3600

ppp multilink

ppp authentication chap pap default

ISDN B-Channel Busyout Example

interface Serial0:23

ip address 172.16.0.0 192.168.0.0

no ip directed-broadcast

encapsulation ppp

no keepalive

dialer idle-timeout 400

dialer load-threshold 1 either

dialer-group 1

isdn switch-type primary-5ess

isdn incoming-voice modem

isdn snmp busyout b-channel

no fair-queue

no cdp enable

Multiple ISDN Switch Types Example

for channelized T1 controller 1.

controller t1 0

framing esf

linecode b8zs

isdn switchtype primary-4ess

!

controller t1 1

framing esf

linecode b8zs

isdn switchtype primary-net5

and is applied only to the PRI interface.

Outgoing B-Channel Ascending Call Order Example

and configures the ISDN outgoing call channel selection to be made in ascending order:

isdn switch-type primary-ni

!

interface serial0:23

isdn bchan-number-order ascending

Static TEI Configuration Example

The following example shows a static TEI configuration:

interface bri 0

isdn static-tei 1

Call Reject Configuration Examples

The following example configures the network to accept incoming ISDN voice calls and reject data calls:

interface Serial4:23

description Connected to V-Sys R2D2

no ip address

isdn switch-type primary-5ess

isdn incoming-voice modem

isdn reject data

no cdp enable

end

The following example sets cause code 21 to reject all incoming data calls:

interface serial 2/0:23

isdn reject data

isdn reject cause 21

ISDN Cause Code Override and Guard Timer Example

The following example shows how to configure cause code override and the ISDN guard timer:

interface Serial0:23

no ip address

no ip directed-broadcast

encapsulation ppp

dialer rotary-group 0

isdn switch-type primary-5ess

isdn incoming-voice modem

isdn disconnect-cause 17

isdn guard-timer 3000 on-expiry accept

isdn calling-number 8005551234

no fair-queue

no cdp enable

PRI Groups and Channel Groups on the Same Channelized T1 Controller Example

command cannot have overlapping time slots; note the correct time slot configuration in this example.

controller t1 0

channel-group 0 timeslot 1-6

channel-group 1 timeslot 7

channel-group 2 timeslot 8

channel-group 3 timeslot 9-11

pri-group timeslot 12-24

The same type of configuration also applies to channelized E1.

Robbed-Bit Signaling Examples

This section provides sample configurations for the T1 controllers on the Cisco access server. You can configure the 24 channels of a channelized T1 to support ISDN PRI, robbed-bit signaling, channel grouping, or a combination of all three. The following samples are provided:

- Allocating All Channels for Robbed-Bit Signaling Example

- Mixing and Matching Channels—Robbed-Bit Signaling and Channel Grouping

Allocating All Channels for Robbed-Bit Signaling Example

The following example configures all 24 channels to support robbed-bit signaling feature group B on a Cisco access server:

controller T1 0

cas-group 1 timeslots 1-24 type e&m-fgb

Mixing and Matching Channels—Robbed-Bit Signaling and Channel Grouping

The following example shows you how to configure all 24 channels to support a combination of ISDN PRI, robbed-bit signaling, and channel grouping. The range of time slots that you allocate must match the time slot allocations that your central office chooses to use. This is a rare configuration due to the complexity of aligning the correct range of time slots on both ends of the connection.

The following configuration creates serial interfaces 0 to 9, which correspond to ISDN PRI time slots 1 to 10 (shown as serial 1:0 through serial 1:9). The serial line 1:23 is the D channel, which carries the analog signal bits that dial the phone number of the modem and determine if a modem is busy or available. The D channel is automatically created and assigned to time slot 24.

controller T1 0

! ISDN PRI is configured on time slots 1 through 10.

pri-group timeslots 1-10

! Channelized T1 data is transmitted over time slots 11 through 16.

channel-group 11 timeslots 11-16

! The channel-associated signal ear and mouth feature group B is configured on

! virtual signal group 17 for time slots 17 to 23, which are used for incoming

! and outgoing analog calls.

cas-group 17 timeslots 17-23 type e&m-fgb

There is no specific interface, such as the serial interface shown in the earlier examples, that corresponds to the time-slot range.

Switched 56K Configuration Examples

The following switched 56K configuration examples are provided:

- Switched 56K T1 Controller Procedure

- Mixture of Switched 56K and Modem Calls over CT1 CAS Example

- Switched 56K and Analog Modem Calls over Separate T1 CAS Lines Example

- Comprehensive Switched 56K Startup Configuration Example

Switched 56K T1 Controller Procedure

The following procedure shows how to configure one T1 controller on a Cisco access server to support switched 56K digital calls. The Cisco access server has four controllers, which are numbered 0 to 3. If you want all four T1 controllers to support switched 56K calls, then repeat this procedure on each controller.

command:

Device# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

variable with a controller number from 0 to 3.

Device(config)# controller t1 1

command. In this example, all calls coming into controller T1 1 are expected to be switched 56K data calls, not analog modem calls.

Device(config-controller)# cas-group 1 timeslots 1-24 type e&m-fgb service data

Note Be sure your signaling type matches the signaling type specified by the central office or telco on the other end. For a list of supported signaling types and how to collect DNIS, refer to the cas-group command description for the E1 controller card in the Cisco IOS Dial Technologies Command Reference.

).

Device(config-controller)# framing esf

).

Device(config-controller)# linecode b8zs

Mixture of Switched 56K and Modem Calls over CT1 CAS Example

The following example configures one T1 controller to accept incoming switched 56K digital calls and analog modem calls over the same T1 CAS line. Time slots 1 through 10 are provisioned by the telco to support switched 56K digital calls. Time slots 11 through 24 are provisioned to support analog modem calls. Due to the DS0s provisioning, it is impossible for analog modems calls to be sent over the DS0s that map to time slots 1 through 10.

controller T1 0

cas-group 1 timeslots 1-10 type e&m-fgb service data

cas-group 1 timeslots 11-24 type e&m-fgb service voice

framing esf

clock source line primary

linecode b8zs

exit

Switched 56K and Analog Modem Calls over Separate T1 CAS Lines Example

command. Controllers T1 2 and T1 3 are configured to support analog modem calls.

controller T1 0

cas-group 1 timeslots 1-24 type e&m-fgb service data

framing esf

clock source line primary

linecode b8zs

exit

controller T1 1

cas-group 1 timeslots 1-24 type e&m-fgb service data

framing esf

clock source line secondary

linecode b8zs

exit

controller T1 2

cas-group 1 timeslots 1-24 type e&m-fgb service voice

framing esf

clock source internal

linecode b8zs

exit

controller T1 3

cas-group 1 timeslots 1-24 type e&m-fgb service voice

framing esf

clock source internal

linecode b8zs

exit

copy running-config startup-config

Comprehensive Switched 56K Startup Configuration Example

The startup configuration in this section runs on the Cisco access server, as shown in Figure 2. This configuration is for an IP dial-in scenario with a mix of switched 56K calls and modem calls. Switched 56K digital calls come into controllers T1 0 and T1 1. Analog modem calls come into controllers T1 2 and T1 3.

In this example, the switched 56K clients are single endpoints in a remote node configuration. If each switched 56K client were instead a router with a LAN behind it without port address translation (PAT) turned on, then a static address, subnet mask, and route must be configured for each remote endpoint. This configuration would best done through RADIUS.

command. Each serial interface must be individually configured. In most cases, the serial configurations will be identical. To streamline or shorten this configuration task, you might consider using a dialer interface, as shown in the following example.

Note In the following example, only analog modem calls encounter the group asynchronous and line interfaces. Switched 56K calls encounter the logical serial interfaces and dialer interface.

version xx.x

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

no service udp-small-servers

no service tcp-small-servers

!

hostname 5300

!

aaa new-model

aaa authentication login default local

aaa authentication login console enable

aaa authentication login vty local

aaa authentication login dialin radius

aaa authentication ppp default local

aaa authentication ppp dialin if-needed radius

aaa authorization exec local radius

aaa authorization network radius

aaa accounting network start-stop radius

aaa accounting exec start-stop radius

!

enable secret cisco

!

username admin password cisco

async-bootp dns-server 10.1.3.1 10.1.3.2

!

!

! Switched 56K calls come into controllers T1 0 and T1 1. Take note of the keywords

! ”service data” in the cas-group command.

!

controller T1 0

framing esf

clock source line primary

linecode b8zs

cas-group 0 timeslots 1-24 type e&m-fgb service data

!

controller T1 1

framing esf

clock source line secondary

linecode b8zs

cas-group 1 timeslots 1-24 type e&m-fgb service data

!

! Analog modem calls come into controllers T1 2 and T1 3.

!

controller T1 2

framing esf

clock source line internal

linecode b8zs

cas-group 2 timeslots 1-24 type e&m-fgb

!

controller T1 3

framing esf

clock source line internal

linecode b8zs

cas-group 3 timeslots 1-24 type e&m-fgb

!

interface loopback0

ip address 10.1.2.62 255.255.255.192

!

interface Ethernet0

no ip address

shutdown

!

interface FastEthernet0

ip address 10.1.1.11 255.255.255.0

ip summary address eigrp 10.10.1.2.0 255.255.255.192

!

! Interface serial0:0 maps to the first switched 56K channel. The dialer pool-member ! command connects this channel to dialer interface 1.

!

interface Serial0:0

dialer rotary-group 1

!

interface Serial0:1

dialer rotary-group 1

!

interface Serial0:2

dialer rotary-group 1

!

interface Serial0:3

dialer rotary-group 1

!

interface Serial0:4

dialer rotary-group 1

!

interface Serial0:5

dialer rotary-group 1

!

interface Serial0:6

dialer rotary-group 1

!

interface Serial0:7

dialer rotary-group 1

!

interface Serial0:8

dialer rotary-group 1

!

interface Serial0:9

dialer rotary-group 1

!

interface Serial0:10

dialer rotary-group 1

!

interface Serial0:11

dialer rotary-group 1

!

interface Serial0:12

dialer rotary-group 1

!

interface Serial0:13

dialer rotary-group 1

!

interface Serial0:14

dialer rotary-group 1

!

interface Serial0:15

dialer rotary-group 1

!

interface Serial0:16

dialer rotary-group 1

!

interface Serial0:17

dialer rotary-group 1

!

interface Serial0:18

dialer rotary-group 1

!

interface Serial0:19

dialer rotary-group 1

!

interface Serial0:20

dialer rotary-group 1

!

interface Serial0:21

dialer rotary-group 1

!

interface Serial0:22

dialer rotary-group 1

!

! Interface serial 0:23 is the last switched 56K channel for controller T1 0.

!

interface Serial0:23

dialer rotary-group 1

!

! The switched 56K channels for controller T1 1 begin with interface serial 1:0 and end

! with interface serial 1:23.

!

interface Serial1:0

dialer rotary-group 1

!

interface Serial1:1

dialer rotary-group 1

!

interface Serial1:2

dialer rotary-group 1

!

interface Serial1:3

dialer rotary-group 1

!

interface Serial1:4

dialer rotary-group 1

!

interface Serial1:5

dialer rotary-group 1

!

interface Serial1:6

dialer rotary-group 1

!

interface Serial1:7

dialer rotary-group 1

!

interface Serial1:8

dialer rotary-group 1

!

interface Serial1:9

dialer rotary-group 1

!

interface Serial1:10

dialer rotary-group 1

!

interface Serial1:11

dialer rotary-group 1

!

interface Serial1:12

dialer rotary-group 1

!

interface Serial1:13

dialer rotary-group 1

!

interface Serial1:14

dialer rotary-group 1

!

interface Serial1:15

dialer rotary-group 1

!

interface Serial1:16

dialer rotary-group 1

!

interface Serial1:17

dialer rotary-group 1

!

interface Serial1:18

dialer rotary-group 1

!

interface Serial1:19

dialer rotary-group 1

!

interface Serial1:20

dialer rotary-group 1

!

interface Serial1:21

dialer rotary-group 1

!

interface Serial1:22

dialer rotary-group 1

!

interface Serial1:23

dialer rotary-group 1

!

interface Group-Async1

ip unnumbered Loopback0

encapsulation ppp

async mode interactive

peer default ip address pool dialin_pool

no cdp enable

ppp authentication chap pap dialin

group-range 1 96

!

interface Dialer1

ip unnumbered Loopback0

no ip mroute-cache

encapsulation ppp

peer default ip address pool dialin_pool

no fair-queue

no cdp enable

ppp authentication chap pap dialin

!

router eigrp 10

network 10.0.0.0

passive-interface Dialer0

no auto-summary

!

ip local pool dialin_pool 10.1.2.1 10.1.2.96

ip default-gateway 10.1.1.1

ip classless

!

dialer-list 1 protocol ip permit

radius-server host 10.1.1.23 auth-port 1645 acct-port 1646

radius-server host 10.1.1.24 auth-port 1645 acct-port 1646

radius-server key cisco

!

line con 0

login authentication console

line 1 96

autoselect ppp

autoselect during-login

login authentication dialin

modem DialIn

line aux 0

login authentication console

line vty 0 4

login authentication vty

transport input telnet rlogin

!

end

ISDN CAS Examples

This section provides channelized E1 sample configurations for the Cisco access server. You can configure the 30 available channels with CAS, channel grouping, or a combination of the two. The following examples are provided:

- Allocating All Channels for CAS Example

- Mixing and Matching Channels—CAS and Channel Grouping Example

Allocating All Channels for CAS Example

The following interactive example configures channels (also known as time slots) 1 to 30 with ear and mouth channel signaling and feature group B support on a Cisco access server; it also shows that the device displays informative messages about each time slot. signaling messages are sent in the 16th time slot; therefore, that time slot is not brought up.

Device#

%SYS-5-CONFIG_I: Configured from console by console

Device# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Device(config)# controller e1 0

Device(config-controller)# cas-group 1 timeslots 1-31 type e&m-fgb

Device(config-controller)#

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 1 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 2 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 3 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 4 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 5 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 6 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 7 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 8 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 9 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 10 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 11 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 12 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 13 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 14 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 15 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 17 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 18 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 19 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 20 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 21 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 22 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 23 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 24 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 25 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 26 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 27 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 28 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 29 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 30 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 31 is up

Mixing and Matching Channels—CAS and Channel Grouping Example

The following interactive example shows you how to configure an E1 controller to support a combination of CAS and channel grouping. The range of time slots that you allocate must match the time slot allocations that your central office chooses to use. This configuration is rare because of the complexity of aligning the correct range of time slots on both ends of the connection.

Time slots 1 through 15 are assigned to channel group 1. In turn, these time slots are assigned to serial interface 0 and virtual channel group 1 (shown as serial 0:1).

Device(config)# controller e1 0

Device(config-controller)# channel-group 1 timeslots 1-15

Device(config-controller)#

%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0:1, changed state to down

%LINK-3-UPDOWN: Interface Serial0:1, changed state to up

%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0:1, changed state to up

Time slots 17 to 31 are configured with CAS:

Device(config-controller)# cas-group 2 timeslots 17-31 type e&m-fgb

%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0:1, changed state to down

Device(config-controller)#

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 17 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 18 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 19 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 20 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 21 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 22 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 23 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 24 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 25 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 26 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 27 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 28 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 29 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 30 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 31 is up

Device(config-controller)#

E1 R2 Signaling Procedure

The following procedure configures R2 signaling and customizes R2 parameters on controller E1 2 of a Cisco AS5300 access server. In most cases, the same R2 signaling type is configured on each E1 controller.

command:

Device# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

global configuration command. A controller informs the access server how to distribute or provision individual time slots for a connected channelized E1 line. You must configure one E1 controller for each E1 line.

Device(config)# controller e1 2

.

Device(config-controller)# cas-group 1 timeslots 1-31 type ?

e&m-fgb E & M Type II FGB

e&m-fgd E & M Type II FGD

e&m-immediate-start E & M Immediate Start

fxs-ground-start FXS Ground Start

fxs-loop-start FXS Loop Start

p7 P7 Switch

r2-analog R2 ITU Q411

r2-digital R2 ITU Q421

r2-pulse R2 ITU Supplement 7

sas-ground-start SAS Ground Start

sas-loop-start SAS Loop Start

). This example also specifies R2 compelled register signaling and provisions the ANI ADDR option.

Device(config-controller)# cas-group 1 timeslots 1-31 type r2-digital r2-compelled ani

Device(config-controller)#

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 1 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 2 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 3 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 4 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 5 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 6 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 7 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 8 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 9 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 10 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 11 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 12 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 13 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 14 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 15 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 17 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 18 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 19 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 20 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 21 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 22 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 23 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 24 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 25 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 26 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 27 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 28 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 29 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 30 is up

%DSX0-5-RBSLINEUP: RBS of controller 0 timeslot 31 is up

Note The actual R2 CAS is configured on the 16th time slot, which is why the time slot does not come up in the example output. For a description of the supported R2 signaling options, refer to the cas-group command for the E1 controller in the Cisco IOS Dial Technologies Command Reference.

.

Device(config-controller)# cas-custom 1

Device(config-ctrl-cas)# ?

CAS custom commands:

ani-digits Expected number of ANI digits

answer-signal Answer signal to be used

caller-digits Digits to be collected before requesting CallerID

category Category signal

country Country Name

default Set a command to its defaults

dnis-digits Expected number of DNIS digits

exit Exit from cas custom mode

invert-abcd invert the ABCD bits before tx and after rx

ka KA Signal

kd KD Signal

metering R2 network is sending metering signal

nc-congestion Non Compelled Congestion signal

no Negate a command or set its defaults

request-category DNIS digits to be collected before requesting category

unused-abcd Unused ABCD bit values

Device(config-ctrl-cas)# country ?

argentina Argentina

australia Australia

brazil Brazil

china China

colombia Colombia

.

.

.

Device(config-ctrl-cas)# country argentina ?

use-defaults Use Country defaults

<cr>

Device(config-ctrl-cas)# country argentina use-defaults

Note We highly recommend that you specify the default settings of your country. To display a list of supported countries, enter the country? command. The default setting for all countries is ITU.

R1 Modified Signaling Using an E1 Interface Example

The following example shows a configuration sample for R1 modified signaling on a Cisco access sever, using an E1 interface:

version xx.x

service timestamps debug datetime msec

no service password-encryption

!

hostname router

!

enable secret 5 $1$YAaG$L0jTcQ.nMH.gpFYXaOU5c.

!

no modem fast-answer

ip host dirt 10.255.254.254

ip multicast rpf-check-interval 0

isdn switch-type primary-dms100

!

!

controller E1 0

clock source line primary

cas-group 1 timeslots 1-15,17-31 type r1-modified ani-dnis

!

controller E1 1

clock source line secondary

cas-group 1 timeslots 1-15,17-31 type r1-modified ani-dnis

!

controller E1 2

clock source internal

!

controller E1 3

clock source internal

!

interface Ethernet0

ip address 10.19.36.7 255.255.0.0

no ip mroute-cache

!

interface FastEthernet0

no ip address

no ip route-cache

no ip mroute-cache

shutdown

!

interface Group-Async1

ip unnumbered Ethernet0

encapsulation ppp

dialer in-band

dialer idle-timeout 480

dialer-group 1

async dynamic address

async mode interactive

peer default ip address pool DYNAMIC

no fair-queue

no cdp enable

group-range 1 108

!

router igrp 200

network 10.0.0.0

network 192.168.254.0

!

no ip classless

ip route 0.0.0.0 0.0.0.0 Ethernet0

logging source-interface Ethernet0

!

line con 0

exec-timeout 0 0

line 1 108

exec-timeout 0 0

modem InOut

transport input all

line aux 0

line vty 0 4

!

end

R1 Modified Signaling for Taiwan Configuration Example

The following example shows how to configure R1 modified signaling for Taiwan:

service timestamps debug datetime msec

no service password-encryption

!

hostname router

!

enable secret 5 $1$YAaG$L0jTcQ.nMH.gpFYXaOU5c.

!

no modem fast-answer

ip host dirt 192.168.254.254

ip multicast rpf-check-interval 0

isdn switch-type primary-dms100

!

!

controller T1 1/1/0

framing esf

linecode b8zs

cablelength short 133

pri-group timeslots 1-24

fdl att

!

controller T1 1/1/1

framing esf

linecode b8zs

cablelength short 133

cas-group 1 timeslots 1-24 type r1-modified

fdl att

!

controller T1 1/1/2

framing esf

linecode b8zs

cablelength short 133

pri-group timeslots 1-24

fdl att

!

controller T1 1/1/3

framing esf

linecode b8zs

cablelength short 133

pri-group timeslots 1-24

fdl att

!

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007–2009 Cisco Systems, Inc. All rights reserved.

Dialing Number Enhancement

Feature History

Release

Modification

12.2(11)T

This feature was introduced.

This document describes the Asynchronous Line Monitoring feature feature. It includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Configuration Tasks

- Monitoring and Maintaining Asynchronous Line Monitoring feature

- Configuration Examples

- Command Reference

Feature Overview

The Asynchronous Line Monitoring feature feature removes previous restrictions on the number of dialed digits accepted as a valid telephone number in the Called Party number information element (IE) for the National or International numbering types.

Benefits

The Asynchronous Line Monitoring feature feature is a change to the Cisco IOS software that makes the ISDN dialing plan more flexible by allowing a range rather than a restricted number of digits to be accepted for dialing.

Restrictions

The Asynchronous Line Monitoring feature feature was developed for interfaces configured for network-side ISDN where the Called Party IE digits are of National or International numbering types.

Related Documents

, Release 12.2, for more information about configuring network-side ISDN switches.

Supported Platforms

The Asynchronous Line Monitoring feature feature is supported on the following platforms:

Cisco 2600 series

Cisco 3620

Cisco 3640

Cisco 3660

Cisco AS5300 series

Cisco AS5350

Cisco AS5400 series

Cisco AS5800 series

Cisco AS5850

Cisco 7200 series

Determining Platform Support Through Cisco Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Cisco Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.

.

Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:

Supported Standards, MIBs, and RFCs

Standards

None

MIBs

None

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

RFCs

None

Configuration Tasks

No new commands are associated with the Asynchronous Line Monitoring feature feature. See the “Troubleshooting Tips” section for information about verifying numbering plans and switch types configured. See the “Configuration Examples” section for configuration examples.

Troubleshooting Tips

To learn and, if necessary, change the numbering plan and type currently configured on the ISDN interface, perform the following steps:

command in EXEC mode:

Router# debug isdn q931

4w1d: ISDN Se0:23: TX -> SETUP pd = 8 callref = 0x000D

4w1d: Bearer Capability i = 0x8890

4w1d: Channel ID i = 0xA98397

4w1d: Called Party Number i = 0xA1, ’12345’, Plan:ISDN, Type:National

4w1d: ISDN Se0:23: RX <- RELEASE_COMP pd = 8 callref = 0x800D

The Called Party Number report lists the numbering plan and type.

command in interface configuration mode. Use the command line interface help feature to list the choices.

Router(config-if)# isdn map address 78886 plan ?

data Data plan

isdn ISDN plan

national National plan

privacy Private plan

reserved Reserved extension

.

.

.

reserved/7 Reserved value 7

telex TELEX plan

unknown Unknown plan

Router(config-if)# isdn map address 78886 plan isdn type ?

abbreviated Abbreviated type

international International type

national National type

network Network type

reserved Reserved type

reserved/5 Reserved value 5

subscriber Subscriber type

unknown Unknown type

command with the following keywords in interface configuration mode:

Router(config-if)# isdn map address telephone-number plan isdn type national

Monitoring and Maintaining Asynchronous Line Monitoring feature

To monitor and maintain the Asynchronous Line Monitoring feature feature, use the procedure in the “Troubleshooting Tips” section.

You may also find the following EXEC command useful for displaying an extensive report about the ISDN interfaces, including the switch type and the status of ISDN Layers 1 through 3:

Command

Purpose

]

Displays the status of all ISDN interfaces, or just the specified interface.

Configuration Examples

This section provides the following configuration examples:

- Data Call Asynchronous Line Monitoring feature Example

- Voice Call Asynchronous Line Monitoring feature Example

Data Call Asynchronous Line Monitoring feature Example

The following example shows configurations for inserting telephone numbers with varying numbers of digits for data calls.

Figure 1 Data Call Asynchronous Line Monitoring

Peer Router Configuration

interface Serial0:23

ip address 10.10.1.1 255.255.255.0

encapsulation ppp

dialer string 19165551213

dialer-group 1

isdn switch-type primary-ni

isdn map address 19165551213 plan isdn type national

AS5300 Router Configuration

interface Serial0:23

ip address 10.10.1.2 255.255.255.0

encapsulation ppp

dialer string 5551212

dialer-group 1

isdn switch-type primary-ni

isdn protocol-emulate network

Voice Call Asynchronous Line Monitoring feature Example

The following example shows configurations for inserting both PBX and public telephone service telephone numbers with varying numbers of digits for voice calls. The PBX is is configured for National ISDN with numbering type National.

Figure 2 Voice Call Asynchronous Monitoring

Cisco Voice Gateway 1 Configuration

interface Serial0:23

no ip address

isdn switch-type primary-ni

isdn protocol-emulate network

isdn incoming-voice modem

dial-peer voice 100 pots

destination-pattern 50001

no digit-strip

direct-inward-dial

port 0:D

dial-peer voice 200 voip

destination-pattern 14085551213

session target ipv4:10.0.194.2

dtmf-relay h245-signal h245-alphanumeric

Cisco Voice Gateway 2 Configuration

dial-peer voice 100 voip

destination-pattern 50001

session target ipv4:10.0.194.52

dtmf-relay h245-signal h245-alphanumeric

Command Reference

.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007–2009 Cisco Systems, Inc. All rights reserved.

ISDN BCAC and Round-Robin Channel Selection Enhancements

First Published: May 20, 2003

Last Updated: April 12, 2011

The ISDN BCAC and Round-Robin Channel Selection Enhancements feature allows more dynamic control of the ISDN B channels by providing the additional B-Channel Availability Control (BCAC) functionality for configuring message signaling and an enhanced channel selection scheme that adds a round-robin configuration to the existing ascending and descending channel selection schemes already available.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the “Feature Information for ISDN BCAC and Round-Robin Channel Selection Enhancements” section.

An account on Cisco.com is not required.

Contents

- Prerequisites for ISDN BCAC and Round-Robin Channel Selection Enhancements

- Information About ISDN BCAC and Round-Robin Channel Selection Enhancements

- How to Configure the ISDN BCAC and Round-Robin Channel Selection Enhancements

- Configuration Examples for ISDN BCAC and Round-Robin Channel Selection Enhancements

- Additional References

- Feature Information for ISDN BCAC and Round-Robin Channel Selection Enhancements

- Glossary

Prerequisites for ISDN BCAC and Round-Robin Channel Selection Enhancements

You need to be familiar with the BCAC service message signaling procedure and the procedure for configuring ISDN PRI before configuring the commands described in this document. See the “Standards” section for a list of references.

Information About ISDN BCAC and Round-Robin Channel Selection Enhancements

- BCAC Enhancements

- Round-Robin Selection Scheme for ISDN B Channels

- Logging of ISDN Events

- Additional ISDN Switch Types Supported for Network Emulation

BCAC Enhancements

BCAC is a service message signaling procedure used to control the availability of ISDN B channels. BCAC provides a coordinated capability between both ends of a PRI to simultaneously preclude selection of specified B channels for outgoing calls, and reject calls (if channel negotiation is employed, calls may go on another channel) for those same channels. The basic BCAC functionality for the handling of SERV and SERV ACK messages already exists on Cisco routers. In Cisco IOS Release 12.3(1), the software has been enhanced with the following BCAC functionality:

- Provides improved processing of SERV and SERV ACK messages. Even though these messages are already handled in the Cisco IOS software, their processing has been enhanced to more closely align with the behavior described in the standards.

- Provides a mechanism to allow the retransmission of SERV messages.

- Handles SERV message collision cases.

- Provides service status audits for various audit triggers.

- Provides an option, that when set, triggers the exchange of service messages on all channels of the interface when the router is rebooted and when the signaling link comes up.

- Provides a mechanism so that if there is a flood of service messages that need to be sent, the service messages can be throttled to avoid losing them.

- Initializes the B-channel service status upon provisioning.

Round-Robin Selection Scheme for ISDN B Channels

ISDN enhancements introduced in Cisco IOS Release 12.3(1) enable you to select a B channel on a PRI or a nonfacility associated signaling (NFAS) interface in a round-robin fashion. This option is in addition to the ascending or descending channel selection schemes already available.

Logging of ISDN Events

ISDN enhancements introduced in Cisco IOS Release 12.3(1) support syslog logging of the following ISDN events:

- ISDN Layer 2 Up and Down events at severity 3.

- ISDN SERV, SERV ACK, Restart, Restart Ack, and Status Enq messages at severity 4.

- ISDN SERV status audit messages for various triggers at different severities.

Additional ISDN Switch Types Supported for Network Emulation

ISDN enhancements introduced in Cisco IOS Release 12.3(1) extend network emulation capability to the Lucent 4ESS, 5ESS, and Nortel DMS-100 ISDN switch types. These switch types can be configured as network, but not all network-side features are supported.

How to Configure the ISDN BCAC and Round-Robin Channel Selection Enhancements

- Configuring BCAC Service Audit Triggers (optional)

- Configuring BCAC Service State Triggers (optional)

- Configuring BCAC Message Retransmission (optional)

- Configuring B-Channel Selection Order (optional)

- Configuring ISDN Syslog Messages (optional)

Configuring BCAC Service Audit Triggers

Perform this task to configure BCAC service audit triggers.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# interface serial 2:23

Enters interface configuration mode on the specified serial port and channel.

Step 4

Router(config-if)# isdn bcac service audit

Enables BCAC service audits.

Step 5

Router(config-if)# isdn bcac service audit trigger 2

Enables individual BCAC service audit triggers.

Step 6

Specifies that BCAC service audits must be triggered on the entire interface.

Step 7

Exits interface configuration mode and returns to privileged EXEC mode.

Configuring BCAC Service State Triggers

Perform this task to configure BCAC service state triggers.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# interface serial 2:23

Enters interface configuration mode on the specified serial port and channel.

Step 4

Router(config-if)# isdn bcac service update provision

Enables the BCAC service status functionality for provisioning the B channels.

Step 5

Triggers updates of the BCAC service states between peer nodes through exchange of SERV and SERV ACK messages.

Step 6

Exits interface configuration mode and returns to privileged EXEC mode.

Configuring BCAC Message Retransmission

Perform this task to configure retransmission of BCAC service messages.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# interface serial 2:23

Enters interface configuration mode on the specified serial port and channel.

Step 4

Router(config-if)# isdn bcac service timer 600

Changes the value of the BCAC T3M1 or T323 service message timer.

- Valid range is from 500 to 120000 ms, and the default is 120000 ms.

Step 5

Router(config-if)# isdn bcac service retry max retries 5

Specifies the maximum number of times that a BCAC service message can be retransmitted when unacknowledged.

- The default is 2 attempts, and you can enter a number from 0 to 127.

Step 6

Specifies that the BCAC service state of the channel needs to be changed to In-Service, because no acknowledgment message was received.

Step 7

Exits interface configuration mode and returns to privileged EXEC mode.

Configuring B-Channel Selection Order

Perform this task to configure selection order of the ISDN B channels.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# interface serial 2:23

Enters interface configuration mode on the specified serial port and channel.

Step 4

]

Router(config-if)# isdn bchan-number-order ascending round-robin

Configures an ISDN PRI interface to make outgoing call selection in ascending or descending order.

- The optional round-robin keyword adds the round-robin selection functionality to the selection order.

Step 5

Exits interface configuration mode and returns to privileged EXEC mode.

Configuring ISDN Syslog Messages

Perform this task to configure logging of ISDN syslog messages.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# isdn logging

Enables logging of ISDN syslog messages.

Step 4

Exits global configuration mode and returns to privileged EXEC mode.

Configuration Examples for ISDN BCAC and Round-Robin Channel Selection Enhancements

- Example: Configuring BCAC Service Audit Triggers

- Example: Configuring BCAC Service State Triggers

- Example: Configuring BCAC Message Retransmission

- Example: Configuring B-Channel Selection Order

- Example: Configuring ISDN Syslog Messages

Example: Configuring BCAC Service Audit Triggers

The following example shows how to enable service audits on serial interface 4:23:

interface serial 4:23

isdn bcac service audit

The following example shows how to disable service trigger 4 on serial interface 4:23:

interface serial 4:23

no isdn bcac service audit trigger 4

command for a list of triggers that can be disabled.

The following example shows how to configure service audits on the entire interface:

interface serial 4:23

isdn bcac service audit interface

Example: Configuring BCAC Service State Triggers

The following example shows how to enable the SERV status message for provisioning the B channels on serial interface 4:23:

interface serial 4:23

isdn bcac service update provision

The following example shows how to trigger service state updates on serial interface 4:23:

interface serial 4:23

isdn bcac service update linkup

Example: Configuring BCAC Message Retransmission

The following example shows how to configure an option whereby, on service message exchange failure, the service state of the concerned channel or channels will be set to In-Service:

interface serial 2:23

isdn bcac service retry in-serv-on-fail

The following example shows how to set the maximum number of service message retransmissions on serial interface 2:23 to 50:

interface serial 2:23

isdn bcac service retry max 50

The following example shows how to change the service timers to 600 ms on serial interface 2:23:

interface serial 2:23

isdn bcac service timer 600

Example: Configuring B-Channel Selection Order

The following example configures the outgoing B channel selection order on a PRI interface to be round-robin in ascending order:

interface serial 5:10

isdn bchan-number-order ascending round-robin

Example: Configuring ISDN Syslog Messages

The following example shows how to configure ISDN syslog logging:

isdn logging

Additional References

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Commands List, All Releases

Dial commands

Fax, modem, and text support over IP configuration

ISDN voice commands

ISDN voice configuration

Standards

Standard

Title

AT&T PRI

; “User Network Interface Description,” 1999.

National ISDN Council (NIC) PRI

, June 1993.

, 1996.

Nortel PRI

.

MIBs

MIB

MIBs Link

None

To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:

RFCs

RFC

Title

None

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Feature Information for ISDN BCAC and Round-Robin Channel Selection Enhancements

lists the release history for this feature.

. An account on Cisco.com is not required.

Note Table 1 lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Table 1 Feature Information for ISDN BCAC and Round-Robin Channel Selection Enhancements

Feature Name

Releases

Feature Information

ISDN BCAC and Round-Robin Channel Selection Enhancements

12.3(1)

The ISDN BCAC and Round-Robin Channel Selection Enhancements feature allows more dynamic control of the ISDN B channels by providing the additional B-Channel Availability Control (BCAC) functionality for configuring message signaling and an enhanced channel selection scheme that adds round-robin configuration to the existing ascending and descending channel selection schemes already available.

.

Glossary

—private branch exchange.

—restart message.

—restart acknowledge message.

—service message.

—service acknowledge message.

—status enquiry message.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2003– 2011 Cisco Systems, Inc. All rights reserved.

Configuring ISDN Special Signaling

This chapter describes features that either depend on special signaling services offered by an ISDN network service provider or overcome an inability to deliver certain signals. It describes these features in the following main sections:

- How to Configure ISDN Special Signaling

- Troubleshooting ISDN Special Signaling

- Configuration Examples for ISDN Special Signaling

hapter.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

How to Configure ISDN Special Signaling

To configure special signaling features of ISDN, perform the tasks in the following sections; all tasks are optional:

- Configuring ISDN AOC (Optional)

- Configuring NFAS on PRI Groups (Optional)

- Enabling an ISDN PRI to Take PIAFS Calls on MICA Modems (Optional)

- Configuring Automatic Detection of Encapsulation Type (Optional)

- Configuring Encapsulation for Combinet Compatibility (Optional)

See the section “Configuration Examples for ISDN Special Signaling” at the end of this chapter for examples of these signaling features. See the “Troubleshooting ISDN Special Signaling” section later in this chapter for help in troubleshooting ISDN signaling features.

Configuring ISDN AOC

ISDN Advice of Charge (AOC) allows users to obtain charging information for all calls during the call (AOC-D) or at the end of the call (AOC-E) or both.

Users must have subscribed through their local ISDN network to receive the AOC information from the switch. No router configuration changes are required to retrieve this call charging information.

The ISDN AOC feature also supports, for the AOC-D service, an optional configurable short-hold mode that provides a dynamic idle timeout by measuring the call charging period, based on the frequency of the AOC-D or the AOC-E message from the network. The short-hold mode allows users to track call costs and to control and possibly reduce tariff charges. The short-hold mode idle time will do the following:

- Disconnect a call just before the beginning of a new charging period if the call has been idle for at least the configured minimum idle time.

- Maintain the call to the end of the current charging period past the configured idle timeout if the time left in the charging period is longer.

Incoming calls are disconnected using the static dialer idle timeout value.

command. Call accounting information from AOC-D and AOC-E messages is stored in Simple Network Management Protocol (SNMP) MIB objects.

ISDN AOC is provided for ISDN PRI NET5 and ISDN BRI NET3 switch types only. AOC information at call setup is not supported.

Configuring Short-Hold Mode

120 seconds. If the short-hold option is not configured, the router default is to use the static dialer idle timeout. If the short-hold idle timeout has been configured but no charging information is available from the network, the static dialer idle timeout applies.

To configure an ISDN interface and provide the AOC short-hold mode option on an ISDN interface, perform the following steps:

command:

- BRI interface— basic-net3

- PRI interface— primary-net5

Step 2 Configure dialer profiles or legacy dial-on-demand routing (DDR) for outgoing calls, as described in the chapters in the “Dial-on-Demand Routing” part of this publication, making sure to do the following:

- Configure the static line-idle timeout to be used for incoming calls.

- For each destination, use the dialer map command with the class keyword (legacy DDR) or a dialer string class command (dialer profiles) to identify the dialer map class to be used for outgoing calls to the destination.

Step 3 Configure each specified dialer map class, providing a dialer idle timeout, or ISDN short-hold timeout, or both for outgoing calls, as described in this chapter.

To configure a dialer map class with timers, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Specifies the dialer map class and begins map class configuration mode.

Step 2

(Optional) Specifies a static idle timeout for the map class to override the static line-idle timeout configured on the BRI interface.

Step 3

Specifies a dialer ISDN short-hold timeout for the map class.

Monitoring ISDN AOC Call Information

To monitor ISDN AOC call information, use the following command in EXEC mode:

Command

Purpose

keyword displays AOC charging time units used during the call and indicates whether the AOC information is provided during calls or at the end of calls.

keyword is available for PRI only.)

Configuring NFAS on PRI Groups

ISDN Non-Facility Associated Signaling (NFAS) allows a single D channel to control multiple PRI interfaces. A backup D channel can also be configured for use when the primary NFAS D channel fails.

Use of a single D channel to control multiple PRI interfaces can free one B channel on each interface to carry other traffic.

Any hard failure causes a switchover to the backup D channel and currently connected calls remain connected.

Once the channelized T1 controllers are configured for ISDN PRI, only the NFAS primary D channel must be configured; its configuration is distributed to all the members of the associated NFAS group.

ISDN NFAS Prerequisites

shows the Cisco IOS keywords for the ISDN switch types and lists whether NFAS is supported.

Table 1 ISDN Switch Types and NFAS Support

Switch Type

Keyword

NFAS Support

Lucent 4ESS Custom NFAS

Yes

Lucent 5ESS Custom NFAS

No (use National)

Nortel DMS Custom NFAS

Yes

NTT Custom NFAS

Yes

National

Yes

Other switch types

—

No (use National)

Note On the Nortel (Northern Telecom) DMS-100 switch, when a single D channel is shared, multiple PRI interfaces may be configured in a single trunk group. The additional use of alternate route indexing, which is a feature of the DMS-100 switch, provides a rotary from one trunk group to another. This feature enables the capability of building large trunk groups in a public switched network.

The ISDN switch must be provisioned for NFAS. The primary and backup D channels should be configured on separate T1 controllers. The primary, backup, and B-channel members on the respective controllers should be the same as that configured on the router and ISDN switch. The interface ID assigned to the controllers must match that of the ISDN switch.

ISDN NFAS Configuration Task List

To configure NFAS on channelized T1 controllers configured for ISDN, perform the tasks in the following section: Configuring NFAS on PRI Groups (required).

You can also disable a channel or interface, if necessary, and monitor NFAS groups and ISDN service. To do so, perform the tasks in the following sections:

- Configuring NTT PRI NFAS (Optional)

- Disabling a Channel or Interface (Optional)

- Monitoring NFAS Groups (Optional)

- Monitoring ISDN Service (Optional)

See the section “NFAS Primary and Backup D Channels” later in this chapter for ISDN, NFAS, and DDR configuration examples.

Configuring NFAS on PRI Groups

command to specify the following values for the associated channelized T1 controllers configured for ISDN:

- The range of PRI time slots to be under the control of the D channel (time slot 24).

- The function to be performed by time slot 24 (primary D channel, backup, or none); the latter specifies its use as a B channel.

- The group identifier number for the interface under control of the D channel.

To configure ISDN NFAS, use the following commands in controller configuration mode:

Command

Purpose

Step 1

On one channelized T1 controller, configures the NFAS primary D channel.

Step 2

On a different channelized T1 controller, configures the NFAS backup D channel to be used if the primary D channel fails.

Step 3

(Optional) On other channelized T1 controllers, configures a 24-B-channel interface, if desired.

For an example of configuring three T1 controllers for the NFAS primary D channel, the backup D channel, and 24 B channels, along with the DDR configuration for the PRI interface, see the section “NFAS Primary and Backup D Channels” at the end of this chapter.

When a backup NFAS D channel is configured and the primary NFAS D channel fails, rollover to the backup D channel is automatic and all connected calls stay connected.

If the primary NFAS D channel recovers, the backup NFAS D channel remains active and does not switch over again unless the backup NFAS D channel fails.

Configuring NTT PRI NFAS

Addition of the NTT switch type to the NFAS feature allows its use in geographic areas where NTT switches are available. This feature provides use of a single D channel to control multiple PRI interfaces, and can free one B channel on each interface to carry other traffic.

switch type.

Note You cannot configure a backup D channel for the NTT PRI NFAS feature; it does not support D channel backup.

Verifying NTT PRI NFAS

command to learn whether the ISDN PRI switch type was configured correctly:

Router# show isdn status serial 0:23

Global ISDN Switchtype = primary-ntt

ISDN Serial0:23 interface

command to display information about members of an NFAS group:

Router# show isdn nfas group 1

ISDN NFAS GROUP 1 ENTRIES:

The primary D is Serial1/0:23.

The NFAS member is Serial2/0:23.

There are 3 total nfas members.

There are 93 total available B channels.

The primary D-channel is DSL 0 in state INITIALIZED.

The current active layer 2 DSL is 0.

command to display information about ISDN channels and the service states:

Router# show isdn service

PRI Channel Statistics:

ISDN Se1/0:23, Channel (1-24)

Configured Isdn Interface (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

Channel (1-24) 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

ISDN Se1/1:23, Channel (1-24)

Configured Isdn Interface (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 0

Channel (1-24) 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

ISDN Se2/0:23, Channel (1-24)

Configured Isdn Interface (dsl) 2

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 0

Channel (1-24) 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

Disabling a Channel or Interface

You can disable a specified channel or an entire PRI interface, thus taking it out of service or placing it into one of the other states that is passed in to the switch. To disable a specific channel or PRI interface, use one of the following commands in interface configuration mode as appropriate for your network:

Command

Purpose

Takes an individual B channel out of service or sets it to a different state.

Sets the entire PRI to the specified state.

are as follows:

- 0—In service

- 1—Maintenance

- 2—Out of service

When the T1 Controller Is Shut Down

In the event that a controller belonging to an NFAS group is shut down, all active B-channel calls on the controller that is shut down will be cleared (regardless of whether the controller is set to be primary, backup, or none), and one of the following events will occur:

- If the controller that is shut down is configured as the primary and no backup is configured, all active calls on the group are cleared.

- If the controller that is shut down is configured as the primary, and the active (In service) D channel is the primary and a backup is configured, then the active D channel changes to the backup controller.

- If the controller that is shut down is configured as the primary, and the active D channel is the backup, then the active D channel remains as backup controller.

- If the controller that is shut down is configured as the backup, and the active D channel is the backup, then the active D channel changes to the primary controller.

Note The active D channel changeover between primary and backup controllers happens only when one of the link fails and not when the link comes up. The T309 timer is triggered when the changeover takes place.

Monitoring NFAS Groups

To monitor NFAS groups, use the following command in EXEC mode:

Command

Purpose

Displays information about members of an NFAS group.

Monitoring ISDN Service

To display information about ISDN channel service states, use the following command in EXEC mode:

Command

Purpose

Displays information about ISDN channels and the service states.

Enabling an ISDN PRI to Take PIAFS Calls on MICA Modems

The Personal-Handyphone-System Internet Access Forum Standard (PIAFS) specifications describe a transmission system that uses the PHS 64000 bps/32000 bps unrestricted digital bearer on the Cisco AS5300 universal access server platform.

The PIAFS TA (terminal adapter) module is like a modem or a V.110 module in the following ways:

- Ports will be a pool of resources.

- Calls will use the same call setup Q.931 message.

- Module supports a subset of common AT commands.

- Call setup and teardown are similar.

However, the rate negotiation information will be part of the bearer cap and not the lower-layer compatibility. PIAFS calls will have the user rate as 32000 and 64000; this will be used to distinguish a PIAFS call from a V.110 call. Also, PIAFS will use only up to octets 5a in a call setup message. The data format will default to 8N1 for PIAFS calls.

To configure ISDN PRI to take PIAFS call on MICA modems, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Router(config)# interface serial controller:channel

Enters interface configuration mode for a D-channel serial interface.

Step 2

Router(config-if)# isdn piafs-enabled

Enables the PRI to take PIAFS calls on MICA modems.

Step 3

Router(config-if)# exit

Exits interface configuration mode.

Verifying PIAFS

command to view PIAFS call information.

Router# show modem op 1/32

Mdm Typ Status Tx/Rx G Duration RTS CTS DCD DTR

1/32 ISDN Conn 64000/64000 0 1d01h x x x x

Modem 1/32, Mica Hex Modem (Managed), Async33, tty33

Firmware Rev: 8.2.0.c

Modem config: Incoming and Outgoing

Protocol: PIAFS, Compression: V.42bis both

Management config: Status polling

RX signals: 0 dBm

Last clearing of "show modem" counters never

2 incoming completes, 0 incoming failures

0 outgoing completes, 0 outgoing failures

0 failed dial attempts, 0 ring no answers, 0 busied outs

0 no dial tones, 0 dial timeouts, 0 watchdog timeouts

0 no carriers, 0 link failures, 0 resets, 0 recover oob

0 recover modem, 0 current fail count

0 protocol timeouts, 0 protocol errors, 0 lost events

0 ready poll timeouts

Configuring Automatic Detection of Encapsulation Type

You can enable a serial or ISDN interface to accept calls and dynamically change the encapsulation in effect on the interface when the remote device does not signal the call type. For example, if an ISDN call does not identify the call type in the lower-layer compatibility fields and is using an encapsulation that is different from the one configured on the interface, the interface can change its encapsulation type dynamically.

This feature enables interoperation with ISDN terminal adapters that use V.120 encapsulation but do not signal V.120 in the call setup message. An ISDN interface that by default answers a call as synchronous serial with PPP encapsulation can change its encapsulation and answer such calls.

Automatic detection is attempted for the first 10 seconds after the link is established or the first 5 packets exchanged over the link, whichever is first.

To enable automatic detection of encapsulation type, use the following command in interface configuration mode:

Command

Purpose

Enables automatic detection of encapsulation type on the specified interface.

You can specify one or more encapsulations to detect. Cisco IOS software currently supports automatic detection of PPP and V.120 encapsulations.

Configuring Encapsulation for Combinet Compatibility

Historically, Combinet devices supported only the Combinet Proprietary Protocol (CPP) for negotiating connections over ISDN B channels. To enable Cisco routers to communicate with those Combinet bridges, the Cisco IOS supports a the CPP encapsulation type.

To enable routers to communicate over ISDN interfaces with Combinet bridges that support only CPP, use the following commands in interface configuration mode:

Command

Purpose

Step 1

Specifies CPP encapsulation.

Step 2

Enables CPP callback acceptance.

Step 3

Enables CPP authentication.

Most Combinet devices support PPP. Cisco routers can communicate over ISDN with these devices by using PPP encapsulation, which supports both routing and fast switching.

Cisco 700 and 800 series routers and bridges (formerly Combinet devices) support only IP, Internet Protocol Exchange (IPX), and bridging. For AppleTalk, Cisco routers automatically perform half-bridging with Combinet devices. For more information about half-bridging, see the section “Configuring PPP Half-Bridging” in the chapter “Configuring Media-Independent PPP and Multilink PPP” later in this publication.

Cisco routers can also half-bridge IP and IPX with Combinet devices that support only CPP. To configure this feature, you only need to set up the addressing with the ISDN interface as part of the remote subnet; no additional commands are required.

Troubleshooting ISDN Special Signaling

To troubleshoot ISDN, use the following commands in EXEC mode as needed:

Command

Purpose

Displays the values of timers.

]

or

Displays link layer information for all interfaces or, optionally, for a single BRI interface.

Displays link layer information for a single PRI interface.

]

or

Displays the content of call control messages and information elements, in particular the Facility IE message for all interfaces or, optionally, for a single BRI interface.

Displays the content of call control messages and information elements, in particular the Facility IE message for a single PRI interface.

Configuration Examples for ISDN Special Signaling

This section provides the following configuration examples:

- ISDN AOC Configuration Examples

- ISDN NFAS Configuration Examples

ISDN AOC Configuration Examples

This section provides the following ISDN AOC configuration examples:

- Using Legacy DDR for ISDN PRI AOC Configuration

- Using Dialer Profiles for ISDN BRI AOC Configuration

Using Legacy DDR for ISDN PRI AOC Configuration

This example shows ISDN PRI configured on an E1 controller. Legacy DDR is configured on the ISDN D channel (serial interface 0:15) and propagates to all ISDN B channels. A static dialer idle-timeout is configured for all incoming calls on the B channels, but the map classes are configured independently of it. Map classes Kappa and Beta use AOC charging unit duration to calculate the timeout for the call. A short-hold idle timer is set so that if the line is idle for 10 or more seconds, the call is disconnected when the current charging period ends. Map class Iota uses a static idle timeout.

version 11.2

service timestamps debug datetime msec

service timestamps log datetime msec

!

hostname A

!

username c2503isdn password 7 1511021F0725

username B password 7 110A1016141D29

username C password 7 1511021F072508

isdn switch-type primary-net5

!

controller E1 0

pri-group timeslots 1-31

!

interface Serial 0:15

ip address 10.0.0.35 255.0.0.0

encapsulation ppp

dialer idle-timeout 150

dialer map ip 10.0.0.33 name c2503isdn class Iota 06966600050

dialer map ip 10.0.0.40 name B class Beta 778578

dialer map ip 10.0.0.45 name C class Kappa 778579

dialer-group 1

ppp authentication chap

!

map-class dialer Kappa

dialer idle-timeout 300

dialer isdn short-hold 120

!

map-class dialer Iota

dialer idle-timeout 300

!

map-class dialer Beta

dialer idle-timeout 300

dialer isdn short-hold 90

!

dialer-list 1 protocol ip permit

Using Dialer Profiles for ISDN BRI AOC Configuration

This example shows ISDN BRI configured as a member of two dialer pools for dialer profiles.

version 11.2

service timestamps debug datetime msec

service timestamps log datetime msec

!

hostname delorean

!

username spanky password 7 0705344245

username delorean password 7 1511021F0725

isdn switch-type basic-net3

!

interface BRI0

description Connected to NTT 81012345678901

no ip address

dialer pool-member 1 max-link 1

dialer pool-member 2 max-link

encapsulation ppp

no fair-queue

!

interface Dialer1

ip address 10.1.1.8 255.255.255.0

encapsulation ppp

dialer remote-name spanky

dialer string 81012345678902 class Omega

dialer pool 1

dialer-group 1

ppp authentication chap

!

interface Dialer2

ip address 10.1.1.8 255.255.255.0

encapsulation ppp

dialer remote-name dmsisdn

dialer string 81012345678902 class Omega

dialer string 14153909503 class Gamma

dialer pool 2

dialer-group 1

ppp authentication chap

!

map-class dialer Omega

dialer idle-timeout 60

dialer isdn short-hold 150

!

map-class dialer Gamma

dialer isdn short-hold 60

!

dialer-list 1 protocol ip permit

ISDN NFAS Configuration Examples

This section provides the following configuration examples:

- NFAS Primary and Backup D Channels

- PRI Interface Service State

- NTT PRI NFAS Primary D Channel Example

NFAS Primary and Backup D Channels

The following example configures ISDN PRI and NFAS on three T1 controllers of a Cisco 7500 series router. The NFAS primary D channel is configured on the 1/0 controller, and the NFAS backup D channel is configured on the 1/1 controller. No NFAS D channel is configured on the 2/0 controller; it is configured for 24 B channels. Once the NFAS primary D channel is configured, it is the only interface you see and need to configure; DDR configuration for the primary D channel—which is distributed to all B channels—is also included in this example.

isdn switch-type primary-4ess

!

! NFAS primary D channel on the channelized T1 controller in 1/0.

controller t1 1/0

framing esf

linecode b8zs

pri-group timeslots 1-24 nfas_d primary nfas_interface 0 nfas_group 1

!

! NFAS backup D channel on the channelized T1 controller in 1/1.

controller t1 1/1

framing esf

linecode b8zs

pri-group timeslots 1-24 nfas_d backup nfas_interface 1 nfas_group 1

!

! NFAS 24 B channels on the channelized T1 controller in 2/0.

controller t1 2/0

framing esf

linecode b8zs

pri-group timeslots 1-24 nfas_d none nfas_interface 2 nfas_group 1

!

! NFAS primary D channel interface configuration for PPP and DDR. This

! configuration is distributed to all the B channels in NFAS group 1 on the

! three channelized T1 controllers.

!

interface Serial 1/0:23

ip address 10.1.1.2 255.255.255.0

no ip mroute-cache

encapsulation ppp

dialer map ip 10.1.1.1 name flyboy 567898

dialer map ip 10.1.1.3 name flyboy 101112345678

dialer map ip 10.1.1.4 name flyboy 01112345678

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap

PRI Interface Service State

The following example puts the entire PRI interface back in service after it previously had been taken out of service:

isdn service dsl 0 b-channel 0 state 0

NTT PRI NFAS Primary D Channel Example

The following example configures ISDN PRI and NFAS on three T1 controllers of a Cisco 7500 series router. The NFAS primary D channel is configured on the 1/0 controller. No NFAS D channel is configured on the 1/1 and 2/0 controllers; they are configured for 24 B channels. Once the NFAS primary D channel is configured, it is the only interface you see and need to configure. DDR configuration for the primary D channel—which is distributed to all B channels—is also included in this example.

isdn switch-type primary-ntt

!

! NFAS primary D channel on the channelized T1 controller in 1/0.

controller t1 1/0

framing esf

linecode b8zs

pri-group timeslots 1-24 nfas_d primary nfas_interface 0 nfas_group 1

!

! NFAS backup D channel on the channelized T1 controller in 1/1.

controller t1 1/1

framing esf

linecode b8zs

pri-group timeslots 1-24 nfas_d none nfas_interface 1 nfas_group 1

!

! NFAS 24 B channels on the channelized T1 controller in 2/0.

controller t1 2/0

framing esf

linecode b8zs

pri-group timeslots 1-24 nfas_d none nfas_interface 2 nfas_group 1

!

! NFAS primary D channel interface configuration for PPP and DDR. This

! configuration is distributed to all the B channels in NFAS group 1 on the

! three channelized T1 controllers.

!

interface Serial 1/0:23

ip address 10.1.1.2 255.255.255.0

no ip mroute-cache

encapsulation ppp

dialer map ip 10.1.1.1 name flyboy 567898

dialer map ip 10.1.1.3 name flyboy 101112345678

dialer map ip 10.1.1.4 name flyboy 01112345678

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007-2009 Cisco Systems, Inc. All rights reserved.

Configuring Network Side ISDN PRI Signaling, Trunking, and Switching

This chapter describes the Network Side ISDN PRI Signaling, Trunking, and Switching feature. The following main sections are provided:

- Network Side ISDN PRI Signaling Overview

- How to Configure Network Side ISDN PRI

- Configuration Examples for Network Side ISDN PRI Signaling, Trunking, and Switching

For hardware technical descriptions and for information about installing the controllers and interfaces, refer to the hardware installation and maintenance publication for your particular product.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

Network Side ISDN PRI Signaling Overview

The Network Side ISDN PRI Signaling, Trunking, and Switching feature enables Cisco IOS software to replicate the public switched network interface to a PBX that is compatible with the National ISDN (NI) switch types and European Telecommunications Standards Institute (ETSI) Net5 switch types.

Routers and PBXs are both traditionally customer premises equipment (CPE) devices with respect to the public switched network interfaces. However, for Voice over IP (VoIP) applications, it is desirable to interface access servers to PBXs with the access server representing the public switched network.

Enterprise organizations use the current VoIP features with Cisco products as a method to reduce costs for long distance phone calls within and outside their organizations. However, there are times that a call cannot go over VoIP and the call needs to be placed using the Public Switched Telephone Network (PSTN). The customer then must have two devices connected to a PBX to allow some calls to be placed using VoIP and some calls to be placed over the PSTN. In contrast, this feature allows Cisco access servers to connect directly to user-side CPE devices such as PBXs and allows voice calls and data calls to be placed without requiring two different devices to be connected to the PBXs.

The Network Side ISDN PRI Signaling, Trunking, and Switching feature provides the following benefits:

- Allows you to bypass PSTN tariffed services such as trunking and administration, thus extending the cost savings of VoIP.

- Allows your PBXs to be connected directly to a Cisco access server, so PBX station calls can be routed automatically to the IP network without the need for special IP telephones.

- Provides flexibility in network design.

- Enables you to block calls selectively based on the called number or the calling number.

Call Switching Using Dial Peers

Call switching using dial peers enables Cisco VoIP gateways to switch both voice and data calls between different interfaces based on the dial peer matching. An incoming call is matched against configured dial peers, and based on the configured called number, the outgoing interface is selected. Any call that arrives from an ISDN PRI network side on a supported platform is either terminated on the access server, switched to an IP network, or switched to the PSTN, depending on the configuration.

Note An incoming call will be switched or processed as a voice call only if it matches a dial peer.

call leg originates from the access server.

For inbound call legs, a dial peer might be associated with the calling number or the port designation. Outbound call legs always have a dial peer associated with them. The destination pattern (a defined initial part of a phone number) is used to identify the outbound dial peer. The call is associated with the outbound dial peer at setup time.

POTS dial peers associate a telephone number with a particular voice port so that incoming calls for that telephone number can be received and outgoing calls can be placed.

, Release 12.2.

Trunk Group Resource Manager

The Trunk Group Resource Manager (TGRM) supports the logical grouping, configuration, and joint management of one or more PRI interfaces. The TGRM is used to store configuration information and to accept or select an interface from a trunk group when requested. A trunk group is provisioned as the target of a dial peer, and the TGRM transparently selects the specific PRI interface and channels to use for incoming or outgoing calls. Trunks are selected based on usage: The trunk that is least used is selected.

Using trunk groups simplifies the task of configuring dial peers and PRI interfaces, and also enables the dynamic selection of PRI interfaces as needed in the access server.

A trunk group can include any number of PRI interfaces, but all the interfaces in a trunk group must use the same type of signaling.

Class of Restrictions

The class of restrictions (COR) functionality provides the ability to deny certain call attempts based on the incoming and outgoing class of restrictions provisioned on the dial peers. This functionality provides flexibility in network design, allows users to block calls (for example, to 900 numbers), and applies different restrictions to call attempts from different originators.

COR is used to specify which incoming dial peer can use which outgoing dial peer to make a call. Each dial peer can be provisioned with an incoming and an outgoing COR list. The incoming COR list indicates the capability of the dial peer to initiate certain classes of calls. The outgoing COR list indicates the capability required for an incoming dial peer to deliver a call via this outgoing dial peer. If the capabilities of the incoming dial peer are not the same or a superset of the capabilities required by the outgoing dial peer, the call cannot be completed using this outgoing dial peer.

ISDN Disconnect Timers

command. The T306 timer is supported only on routers that are configured for network-side ISDN. The following switches support network-side ISDN:

- National ISDN

- NET3 BRI

- NET5

- QSIG

command.

How to Configure Network Side ISDN PRI

See the following sections for configuration tasks for the Network Side ISDN PRI Signaling, Trunking, and Switching feature. Each task is identified as required or optional.

- Configuring ISDN Network Side (Required)

- Configuring Global or Interface Trunk Groups (Optional)

- Configuring Classes of Restrictions (Optional)

- Configuring ISDN T306 and T310 Timers (Optional)

- Verifying Network Side ISDN PRI Signaling, Trunking, and Switching (Optional)

The sections “Monitoring Network Side ISDN PRI” and “Monitoring TGRM” list commands that you can use to monitor network side ISDN PRI signaling.

Configuring ISDN Network Side

Before you begin to configure the Network Side ISDN PRI Signaling, Trunking, and Switching feature, ensure that the selected access server is in the following condition:

- The T1 or E1 controllers are operational and configured for ISDN PRI.

- The D-channel interfaces are operational and configured for ISDN PRI.

- Each D-channel interface is configured with the isdn incoming-voice modem command.

For example, the selected PRI interfaces might have a configuration similar to the following:

interface Serial1/0/0:23

no ip address

no ip directed-broadcast

isdn switch-type primary-ni

isdn protocol-emulate network

isdn incoming-voice modem

no cdp enable

Also keep the following restrictions in mind as you configure network side ISDN PRI signaling, trunking, and switching:

- You can configure Cisco access server and access routers for either Network Side ISDN PRI for NI or Net5 switches.

- The trunking and COR parts of the Network Side ISDN PRI Signaling, Trunking, and Switching feature are available only on the Cisco AS5800 access server. In addition, call hairpinning without the need of a Voice Feature Card (and its digital signal processor) is available only on the Cisco AS5800 and Cisco AS5400. The remainder of the feature is platform-independent.

- The Cisco AS5800 and Cisco AS5400 switch both voice and data calls. The Cisco As5300 switches only data calls.

- On the Cisco AS5800, direct-inward-dial (DID) switched calls can work without a Voice Feature Card, if the appropriate modem is present. Refer to the AS5800 hardware and software installation manuals for more information.

- On the Cisco AS5400, direct-inward-dial (DID) switched calls can work with only Trunk Feature Cards present. No Voice Feature Card or Modem Feature card are required.

- An interface that is a member of a Non-Facility Associated Signaling (NFAS) group cannot belong to a trunk group.

- The Cisco AS5400 supports Network Side ISDN PRI Signaling and Calling Switching Using Dial Peers. It does not support Trunk Group Resource Manager and Class of Restrictions.

- The Network Side ISDN PRI part of this feature runs on any ISDN-capable platform with PRI interfaces. The trunking and class of restrictions parts of this feature require the Cisco AS5800.

Note To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

Configuring ISDN Network Side for the National ISDN Switch Type

To configure Network Side ISDN PRI, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Router(config)# isdn switch-type type

or

and

Sets the global ISDN switch type. Two types are supported:

- primary-ni for NI on a T1 line

- primary-net5 for ETSI Net5 on an E1 line

, the D-channel number, use:

on a T1 PRI

on an E1 PRI

Sets the switch type on the interface.

Step 2

Enables network-side support on the PRI interface.

If you choose to configure Network Side ISDN PRI on individual interfaces in Step 1, repeat the configuration on the additional PRI interfaces.

Configuring ISDN Network Side for ETSI Net5 PRI

switch type on selected PRI interfaces. To configure ISDN Network Side for Net5, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

or

global ISDN switch type.

or

Specifies a D-channel interface to configure for ISDN Network Side for ETSI Net5 PRI.

switch type on the interface.

Step 2

Enables network side support on the interface.

Repeat the configuration steps on all the additional PRI D-channel interfaces you want to configure for ISDN Network Side for ETSI Net5 PRI.

Configuring Global or Interface Trunk Groups

You can create trunk groups globally (using the one-command version of Step 1) or on each interface (using the two-command version of Step 1). To configure trunk groups, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Defines the trunk group globally.

or

and

, the D-channel number, use:

- 0:23 on a T1 PRI

- 0:15 on an E1 PRI

Adds the interface to a trunk group. If the trunk group has not been defined globally, it will be created now.

Step 2

Applies a maximum number of calls restriction to the trunk group.

This command can be repeated to apply a maximum number to different types of calls and, optionally, to specify whether the maximum applies to incoming or outgoing calls.

Note Repeat Step 1 and Step 2 to create additional trunk groups and specify their restrictions, as needed for your traffic.

Step 3

Enters dial-peer configuration mode and defines a remote dial peer.

Step 4

Specifies the trunk group to be used for outgoing calls to the destination phone number.

Configuring Classes of Restrictions

To configure COR for dial peers, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Specifies that named classes of restrictions apply to dial peers and changes the command mode to COR configuration.

Step 2

Provides a name for a custom class of restrictions.

Note Repeat this step for additional class names, as needed. These class names are used in various combinations to define the lists in Step 3 and Step 4.

Step 3

Provides a name for a list of restrictions.

Step 4

Adds a COR class to this list of restrictions.

The member is a class named in Step 2.

Step 5

Enters dial-peer configuration mode and defines a remote dial peer.

Step 6

Specifies the COR list to be used when this is the incoming dial peer.

Step 7

Specifies the COR list to be used when this is the outgoing dial peer.

Configuring ISDN T306 and T310 Timers

To configure the T306 and T310 timers, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Enters interface configuration mode for a D-channel serial interface.

Step 2

Sets the number of milliseconds that the gateway waits before clearing a call after the router sends out a disconnect message with a progress indicator of 8.

Step 3

Sets the number of milliseconds that the gateway waits before clearing a call after it receives a Call Proceeding message.

To verify that the T306 timer is configured and operating correctly, perform the following steps:

privileged EXEC command. Verify that the configuration is accurate for the T306 timer. See the “T306/T310 Timer Configuration Example” section for a sample configuration.

privileged EXEC command to trace the ISDN messages.

Step 3 Place a call to the gateway. Disconnect the call and allow the far end to play its error message until the T306 timer expires. When the timer expires, the gateway should disconnect the call.

Verifying Network Side ISDN PRI Signaling, Trunking, and Switching

To learn whether the Network Side ISDN PRI Signaling, Trunking, and Switching feature is configured successfully, perform the following steps:

command to learn whether an appropriate switch type is specified either globally or on the D-channel interface:

Router# show isdn status serial 0:15

Global ISDN Switchtype = primary-net5

ISDN Serial0:15 interface

******* Network side configuration *******

dsl 0, interface ISDN Switchtype = primary-net5

command to learn whether the trunk group COR list and permission fields are set as desired on a dial peer:

Router# show dial-peer voice

VoiceEncapPeer210

information type = voice,

tag = 210, destination-pattern = `221',

answer-address = `', preference=0,

numbering Type = `unknown'

group = 210, Admin state is up, Operation state is up,

incoming called-number = `221', connections/maximum = 4/unlimited,

DTMF Relay = disabled,

Modem = system passthrough ,

huntstop = disabled,

application associated:

permission :both

incoming COR list:listA

outgoing COR list:minimum requirement

type = pots, prefix = `221',

forward-digits default

session-target = `', voice-port = `1/0/8:D',

direct-inward-dial = enabled,

digit_strip = enabled,

Note The above output is for a dial peer configured with incoming COR list “listA” and without an outgoing COR list configured. When no outgoing COR list is configured, the show dial-peer voice command displays “minimum requirement” in the outgoing COR list output. When no incoming COR list is configured, the show dial-peer voice command displays “maximum capability” in the incoming COR list output.

command output reflects that configuration.

Sample Configuration

dial-peer cor custom

name 900block

name 800_call

name Catchall

!

dial-peer cor list list1

member 900block

member 800_call

!

dial-peer cor list list2

member 900block

!

dial-peer cor list list3

member 900block

member 800_call

member Catchall

Verification

Router# show dial-peer cor

Class of Restriction

name:900block

name:800_call

name:Catchall

COR list <list1>

member:900block

member:800_call

COR list <list2>

member:900block

COR list <list3>

member:900block

member:800_call

member:Catchall

command output reflects that configuration.

Sample Configuration

interface Serial1/0/8:15

no ip address

ip mroute-cache

no keepalive

isdn switch-type primary-net5

isdn protocol-emulate network

isdn incoming-voice modem

trunk-group 2

no cdp enable

Verification

Router# show tgrm

Trunk Any in Vce in Data in

Group # Any out Vce out Data out

2 65535 65535 65535

65535 65535 65535

0 Retries

Interface Se1/0/1:15 Data = 0, Voice = 0, Free = 30

Interface Se1/0/8:15 Data = 2, Voice = 0, Free = 28

Total calls for trunk group:Data = 2, Voice = 0, Free = 58

Selected Voice Interface :Se1/0/1:15

Selected Data Interface :Se1/0/1:15

command to display the status of both Network Side ISDN PRI and call switching:

Router# show isdn status

Global ISDN Switchtype = primary-net5

ISDN Serial1/0/0:15 interface

******* Network side configuration *******

dsl 0, interface ISDN Switchtype = primary-net5

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED

Layer 3 Status:

2 Active Layer 3 Call(s)

Activated dsl 0 CCBs = 2

CCB:callid=3C71, sapi=0, ces=0, B-chan=31, calltype=data

CCB:callid=3C72, sapi=0, ces=0, B-chan=30, calltype=data

The Free Channel Mask: 0x9FFF7FFF

ISDN Serial1/0/1:15 interface

/1/0/8

filtering...

ISDN Serial1/0/8:15 interface

******* Network side configuration *******

dsl 8, interface ISDN Switchtype = primary-net5

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED

Layer 3 Status:

2 Active Layer 3 Call(s)

Activated dsl 8 CCBs = 2

CCB:callid=BB40, sapi=0, ces=0, B-chan=1, calltype=DATA

CCB:callid=BB41, sapi=0, ces=0, B-chan=2, calltype=DATA

The Free Channel Mask: 0xFFFF7FFC

Monitoring Network Side ISDN PRI

To monitor Network Side ISDN PRI, use the following commands in EXEC mode as needed:

Command

Purpose

Checks Layer 1 (physical layer) of the PRI over E1.

Displays the number of calls and call durations on an E1 controller.

Displays information about the physical attributes of the ISDN PRI over channelized E1 B and D channels.

}

Displays information about memory, Layer 2 and Layer 3 timers, and the status of PRI channels.

Monitoring TGRM

To monitor and maintain the Trunk Group Resource Manager, use the following command in EXEC mode:

Command

Purpose

Displays TGRM information for debugging purposes.

Configuration Examples for Network Side ISDN PRI Signaling, Trunking, and Switching

This section provides the following configuration examples:

- Call Switching and Dial Peers Configuration on T1/T3 Example

- Trunk Group Configuration Example

- COR for Dial Peer Configuration Example

- COR Based on Outgoing Dial Peers Example

- Dial Peers and Trunk Groups for Special Numbers Examples

- ISDN Network Side for ETSI Net5 PRI Configuration on E1 Example

- T306/T310 Timer Configuration Example

Call Switching and Dial Peers Configuration on T1/T3 Example

The following example enables Network Side ISDN PRI, call switching, and dial peers:

isdn switch-type primary-ni

!

controller T1 1/0/0

framing esf

linecode b8zs

pri-group timeslots 1-24

!

interface Serial1/0/0:23

no ip address

no ip directed-broadcast

isdn switch-type primary-ni

isdn protocol-emulate network

isdn incoming-voice modem

no cdp enable

!

dial-peer voice 11 pots

incoming called-number 222

destination-pattern 222

direct-inward-dial

port 1/0/0:D

prefix 555

Trunk Group Configuration Example

The following trunk group allows only voice calls:

trunk group 1

max-calls data 0

!

The following trunk group allows a maximum of 20 outgoing voice calls:

trunk group 2

max-calls voice 20 direction out

!

The following trunk group allows a maximum of 50 incoming calls:

trunk group 3

max-calls any 50 direction in

!

The following trunk group allows a maximum of 100 calls, 30 of which can be voice (incoming or outgoing), and 60 of which can be incoming data (the remaining 10 will be unused):

trunk group 4

max-calls any 100

max-calls voice 30

max-calls data 60 direction in

COR for Dial Peer Configuration Example

tags for outgoing calls correspond to the destination pattern.

trunk group 101

!

interface Serial1/0/0:23

no ip address

no ip directed-broadcast

isdn switch-type primary-ni

isdn protocol-emulate network

isdn incoming-voice modem

no cdp enable

trunk-group 101

!

interface Serial1/0/1:23

no ip address

no ip directed-broadcast

isdn switch-type primary-ni

isdn protocol-emulate network

isdn incoming-voice modem

no cdp enable

trunk-group 101

!

dial-peer cor custom

name 900_call

name 800_call

!

dial-peer cor list list1

member 900_call

!

dial-peer cor list list2

member 800_call

!

dial-peer cor list list3

member 900_csll

member 800_call

!

dial-peer voice 525 pots

answer-address 408525....

corlist incoming list3

direct-inward-dial

!

dial-peer voice 526 pots

answer-address 408526....

corlist incoming list2

direct-inward-dial

!

dial-peer voice 900 pots

destination-pattern 1900.......

direct-inward-dial

trunkgroup 101

prefix 333

corlist outgoing list1

!

dial-peer voice 12345 pots

destination-pattern .T

direct-inward-dial

trunkgroup 202

!

COR Based on Outgoing Dial Peers Example

that contains COR 5x.

to this incoming dial peer.

config terminal

dial-peer cor custom

name 5x

name 6x

name 1900x

!

dial-peer cor list listA

member 5x

member 6x

!

dial-peer cor list listB

member 5x

member 6x

member 1900x

!

dial-peer cor list list5x

member 5x

!

dial-peer cor list list6x

member 6x

!

dial-peer cor list list1900x

member 1900x

! outgoing dialpeer 100, 200, 300

dial-peer voice 100 pots

destination-pattern 5T

corlist outgoing list5x

dial-peer voice 200 pots

destination-pattern 6T

corlist outgoing list6x

dial-peer voice 300 pots

destination-pattern 1900T

corlist outgoing list1900x

!

! incoming dialpeer 400, 500

dial-peer voice 400 pots

answer-address 525....

corlist incoming listA

dial-peer voice 500 pots

answer-address 526

corlist incoming listB

In this example, calls from 525xxxx are not able to use dial peer 300, which means they will not be able to make 1900 calls (long distance calls to the 900 area code). But calls from 526xxxx can make 1900 calls.

Dial Peers and Trunk Groups for Special Numbers Examples

The following partial examples show setups for handling special numbers such as the 911 emergency number, the 0 local operator number, the 00 long-distance operator number, and so forth. “T” in these examples stands for the “interdigital timeout.” Calls to emergency numbers should not wait for this timeout, so 911 is used as the destination pattern, not 911T.

This partial example sets up a trunk group to handle calls going to the operator (0):

dial-peer voice 100 pots

destination-pattern 0T

trunkgroup 203

!

The following partial example sets up a trunk group to handle calls to the long distance operator (00):

dial-peer voice 200 pots

destination-pattern 00T

trunkgroup 205

!

The following partial example sets up a trunk group to handle calls to the international direct dial (011):

dial-peer voice 300 pots

destination-pattern 011T

trunkgroup 207

!

The following partial example sets up a trunk group to handle street line calls (calls that get a dial tone for an outside line):

disl-peer voice 400 pots

destination-pattern 9T

trunkgroup 209

!

The following partial example sets up a trunk group to handle calls for directory assistance:

dial-peer voice 500 pots

destination-pattern 411

trunkgroup 211

!

The following partial example sets up a trunk group to handle calls to the 911 emergency number. Emergency calls will not require a wait for the interdigital timeout to expire. They will be completed immediately.

dial-peer voice 600 pots

destination pattern 911

trunkgroup 333

ISDN Network Side for ETSI Net5 PRI Configuration on E1 Example

The following example enables the ISDN Network Side for ETSI Net5 PRI feature on an access server on which ISDN PRI is already configured and operational. In this example, the Net5 PRI switch type is set on the D-channel interface, and the global interface type is not shown.

controller e1 0

pri-group timeslots 1-31

exit

!

interface serial0:15

no ip address

no ip directed-broadcast

ip mroute-cache

isdn switch-type primary-net5

isdn protocol-emulate networK

T306/T310 Timer Configuration Example

The following example configures the T306 and T310 disconnect timers:

interface Serial0:23

no ip address

no ip directed-broadcast

encapsulation ppp

dialer rotary-group 0

isdn switch-type primary-5ess

isdn incoming-voice modem

isdn t306 60000

isdn t310 40000

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2007-2009 Cisco Systems, Inc. All rights reserved.

Preparing to Configure DDR

This chapter presents the decisions and preparations leading to a dial-on-demand routing (DDR) configuration and shows where some advanced features fit into the DDR configuration steps. It distinguishes between the topology decisions and the implementation of the decisions. In the implementation phase, it distinguishes the DDR-independent decisions from the DDR-dependent decisions.

This chapter provides the following information:

- DDR Decision Flowchart—A flowchart of topology and implementation decisions that you will need to make before you configure DDR.

- DDR Topology Decisions, DDR-Independent Implementation Decisions, and DDR-Dependent Implementation Decisions—References to sources of detailed information for the configuration steps associated with each decision.

- Global and Interface Preparations for DDR—Brief description indicating which preparations are global and which are interface-specific.

- Preparations for Routing or Bridging over DDR—A description of the steps required for bridging or routing over DDR.

The section “Configuration Examples for Legacy DDR” at the end of this chapter provides examples of configuring DDR in your network, and includes line configuration and chat script samples.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

DDR Decision Flowchart

This section provides a flowchart of the decisions to be made before and while you configure DDR and also includes the flowchart.

Figure 1 presents the entire decision flowchart. The decision phases are shown in separate boxes. Numbers in parentheses refer to notes, which follow the figure.

Figure 1 Decisions and Implementation Flow to DDR

Flowchart Notes

The DDR chapters do not provide complete configuration information for most of the items in the following list. However, detailed information is available in other chapters and publications. The numbers in this list correspond to the circled numbers in the flowchart.

1. Configuration of the dial port and interface. The port, line, and interface are expected to be configured and operational before you configure DDR. See the relevant chapters in the “Preparing for Dial Access” part of this manual.

for sections on Frame Relay and X.25.

.

4. Routed protocols to be supported. See the protocol-specific chapters and publications.

5. Dialer profiles and legacy DDR are described in different chapters of the “Dial-on-Demand Routing” part of this publication.

6. Complex DDR configurations. Refer to the chapter “Configuring Media-Independent PPP and Multilink PPP” in this publication.

The DDR chapters provide complete configuration information about the simple hub-and-spoke DDR configurations, about the dialer profiles implementation of DDR, and about preparations required for configuring asynchronous interfaces for DDR.

DDR Topology Decisions

Topology decisions determine which routers will use DDR, which media and interfaces each one will use for DDR, and how each interface will function when using DDR. For example, if you choose a hub-and-spoke topology, one router will communicate with multiple routers. You must decide whether that router will use one interface or multiple interfaces for DDR, and whether it will receive calls only (forcing the spokes to initiate and bear the cost of calls). If it will use multiple interfaces, you must decide whether they will be of different types or the same type.

DDR-Independent Implementation Decisions

DDR-independent implementation decisions include the following:

- Using a specific interface or combination of interfaces for DDR.

For complete configuration steps for the various media and interfaces, see the chapters in the “Dial-In Port Setup” part of this publication.

- Using nondefault encapsulations.

The default encapsulation is High-Level Data Link Control (HDLC). However, PPP is widely used for situations in which authentication is desired, especially situations in which an interface will receive calls from multiple sites. Detailed PPP encapsulation requirements are described in the “Configuring Media-Independent PPP and Multilink PPP” and “Configuring Asynchronous PPP and SLIP” chapters of this publication.

.

- Routing or bridging the DDR traffic.

Legacy DDR supports bridging to only one destination, but the dialer profiles support bridging to multiple destinations.

.

- Supporting one or more specific routed protocols, if you decide to route traffic.

.

DDR-Dependent Implementation Decisions

You must decide whether to implement legacy DDR or the newer dialer profiles; both are documented in the “Dial-on-Demand Routing” part of this publication. You must also decide whether a simple DDR configuration meets your business needs or whether to add other features.

Dialer Profiles

The dialer profiles implementation of DDR is based on a separation between logical and physical interface configuration. Dialer profiles also allow the logical and physical configurations to be bound together dynamically on a per-call basis.

Dialer profiles are advantageous in the following situations:

- When you want to share an interface (ISDN, asynchronous, or synchronous serial) to place or receive calls.

- When you want to change any configuration on a per-user basis.

- When you want to maximize ISDN channel usage using the Dynamic Multiple Encapsulations feature to configure various encapsulation types and per-user configurations on the same ISDN B channel at different times according to the type of call.

- When you want to bridge to many destinations, and for avoiding split horizon problem.

Most routed protocols are supported; however, International Organization for Standardization Connectionless Network Service (ISO CLNS) is not supported.

If you decide to configure dialer profiles, you must disable validation of source addresses for the routed protocols you support.

For detailed dialer profiles information, see the “Configuring Peer-to-Peer DDR with Dialer Profiles” chapter in this publication. For more information about Dynamic Multiple Encapsulations, see the “How to Configure Dialer Profiles” section in that chapter.

Legacy DDR

Legacy DDR is powerful and comprehensive, but its limitations affect scaling and extensibility. Legacy DDR is based on a static binding between the per-destination call specification and the physical interface configuration.

However, legacy DDR also has many strengths. It supports Frame Relay, ISO CLNS, LAPB, snapshot routing, and all routed protocols that are supported on Cisco routers. By default, legacy DDR supports fast switching.

For information about simple legacy DDR spoke configurations, see the “Configuring Legacy DDR Spokes” chapter. For information about simple legacy DDR hub configurations, see the “Configuring Legacy DDR Hubs” chapter. Both chapters are in this publication.

Simple or Complex DDR Configuration

You must also decide whether to implement a simple DDR configuration—whether it is a simple point-to-point (spoke-to-spoke) layout or a simple hub-and-spoke layout—or to add on features that make the implementation more complex. Add-on features include dial backup, bandwidth on demand, application of the Bandwidth Allocation Control Protocol (BACP), Multilink PPP, and many others.

Global and Interface Preparations for DDR

Some preparations are global and some depend on the type of interface you will configure for DDR. After you have made the required global decision whether to bridge or to route a specified protocol over a dial-on-demand link, you can make the following preparations:

- If you choose to bridge the protocol, decide whether to allow bridge packet access by Ethernet type codes or to permit all bridge packets across the link. Allowing access by Ethernet type codes requires you to define a bridging access list in global configuration mode.

Allowing all bridge packets to trigger calls across a dial-on-demand link to a single destination is a DDR-dependent task addressed in the “Configure Dialer Access Lists to Trigger Outgoing Calls” section of both the “Configuring Legacy DDR Spokes” and “Configuring Legacy DDR Hubs” chapters in this publication.

Bridging to multiple destinations requires dialer profiles.

- If you choose to route the protocol:

– Define one or more access lists for the selected routed protocol to determine which packets should be permitted or denied access to the dial-on-demand link.

Allowing those packets to trigger calls across a dial-on-demand link is a DDR-dependent task addressed in the “Configure Dialer Access Lists to Trigger Outgoing Calls” section of both the “Configuring Legacy DDR Spokes” and “Configuring Legacy DDR Hubs” chapters in this publication.

– Define an appropriate dialer list for the protocol.

– Disable validation of source addresses, if you decide to configure dialer profiles.

Preparations Depending on the Selected Interface Type

The steps shown in this chapter assume that you have also completed the required preparatory steps for the type of interface you will configure for DDR:

- The interface is installed, the cable is connected as needed, and operational.

- Chat scripts are ready, as needed, for any asynchronous interfaces and modem scripts have been assigned to the relevant asynchronous lines.

- Asynchronous lines and modems are configured and operational, as needed.

- Any ISDN line that will be used for DDR is properly provisioned and running.

- You have decided which interfaces and how many interfaces are to be configured for DDR, and what functions each interface will perform.

Preparations for Routing or Bridging over DDR

The following tasks are DDR-independent and can be completed before you configure DDR. Minimal tasks required for each item are presented in this chapter. For detailed information about bridging, routing, and wide-area networking configurations, refer to the appropriate chapters in other manuals of the Cisco IOS documentation set.

Complete the following minimal tasks for the global decisions you have made:

- Preparing for Transparent Bridging over DDR (As required)

- Preparing for Routing over DDR (As required)

Preparing for Transparent Bridging over DDR

To prepare for transparent bridging over DDR, complete the tasks in the following sections:

- Defining the Protocols to Bridge (As required)

- Specifying the Bridging Protocol (As required)

- Controlling Bridging Access (As required)

Defining the Protocols to Bridge

IP packets are routed by default unless they are explicitly bridged; all others are bridged by default unless they are explicitly routed. To bridge IP packets, use the following command in global configuration mode:

Command

Purpose

Disables IP routing.

.

Specifying the Bridging Protocol

You must specify the type of spanning-tree bridging protocol to use and also identify a bridge group. To specify the spanning-tree protocol and a bridge group number, use the following command in global configuration mode:

Command

Purpose

}

Defines the type of spanning tree protocol and identifies a bridge group.

The bridge-group number is used when you configure the interface and assign it to a bridge group. Packets are bridged only among members of the same bridge group.

Controlling Bridging Access

, or you can use the finer granularity of controlling access by Ethernet type codes.

To control access by Ethernet type codes, use the following commands in global configuration mode:

Command

Purpose

Step 1

]

Identifies interesting packets by Ethernet type codes (access list numbers must be in the range 200–299).

Step 2

Defines a dialer list for the specified access list.

and cannot trigger calls.

.

To identify all transparent bridge packets as interesting, use the following command in global configuration mode:

Command

Purpose

Defines a dialer list that treats all transparent bridge packets as interesting.

Preparing for Routing over DDR

DDR supports the following routed protocols: AppleTalk, Banyan VINES, DECnet, IP, Internet Protocol Exchange (IPX), ISO CLNS, and Xerox Network Systems (XNS).

To prepare for routing a protocol over DDR, perform the tasks in the relevant section:

- Configuring the Protocol for Routing and Access Control (As required)

- Associating the Protocol Access List with a Dialer Group (As required)

Configuring the Protocol for Routing and Access Control

This section specifies the minimal steps required to configure a protocol for routing over DDR. For more options and more detailed descriptions, refer to the relevant protocol chapter.

Configuring IP Routing

for more information.

At a minimum, you must complete the following tasks:

- Disable validation of source addresses.

- Configure one or more IP access lists before you refer to the access lists in DDR dialer-list commands to specify which packets can trigger outgoing calls.

To disable validation of source addresses, use the following commands in global configuration mode:

Command

Purpose

Specifies the routing protocol; RIP, for example.

Disables validation of source addresses.

Specifies the IP address.

.

To configure IP access lists, use one of the following commands in global configuration mode:

Command

Purpose

]

or

]

Specifies an IP standard access list.

Specifies an IP extended access list.

.

For an example of configuring DDR for IP, see the chapters “Configuring a Legacy DDR Spoke” or “Configuring a Legacy DDR Hub” in this publication.

You can configure IP routing on DDR asynchronous, synchronous serial, and ISDN interfaces, as well as dialer rotary groups.

Configuring Novell IPX Routing

To configure routing of IPX over DDR, you must complete both global and interface-specific tasks:

- Enable IPX routing globally.

- Enable IPX watchdog spoofing, or enable Sequenced Packet Exchange (SPX) keepalive spoofing on the interface.

To enable IPX routing, use the following command in global configuration mode:

Command

Purpose

]

Enables IPX routing.

To enable IPX watchdog spoofing on the interface, use the following command in interface configuration mode:

Command

Purpose

Enables IPX watchdog spoofing.

To enable SPX keepalive spoofing, use the following commands in interface configuration mode:

Command

Purpose

Enables SPX keepalive spoofing.

Sets the idle time after which SPX spoofing begins.

You can configure IPX routing on DDR asynchronous, synchronous serial, and ISDN interfaces, as well as dialer rotary groups.

.

Configuring AppleTalk Routing

keyword.

You can configure AppleTalk routing on DDR asynchronous, synchronous serial, and ISDN interfaces, as well as dialer rotary groups.

See the chapters “Configuring a Legacy DDR Spoke” or “Configuring a Legacy DDR Hub” for more information and examples.

Configuring Banyan VINES Routing

To configure DDR for Banyan VINES, use one of the following commands in global configuration mode:

Command

Purpose

or

]

Specifies a VINES standard access list.

Specifies a VINES extended access list.

keyword. See the chapters “Configuring a Legacy DDR Spoke” or “Configuring a Legacy DDR Hub” for more information and examples.

You can configure Banyan VINES on DDR asynchronous, synchronous serial, and ISDN interfaces, as well as dialer rotary groups.

Note The Banyan VINES neighbor command is not supported for LAPB and X.25 encapsulations.

Configuring DECnet Routing

To configure DDR for DECnet, use one of the following commands in global configuration mode:

Command

Purpose

or

]

Specifies a DECnet standard access list.

Specifies a DECnet extended access list.

keyword. See the chapters “Configuring a Legacy DDR Spoke” or “Configuring a Legacy DDR Hub” in this publication for more information and examples.

.

You can configure DECnet on DDR asynchronous, synchronous serial, and ISDN interfaces, as well as dialer rotary groups.

Configuring ISO CLNS Routing

To configure ISO CLNS for DDR, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Specifies one or more CLNS filters, repeating this command as needed to build the filter list associated with the filter name.

Step 2

Specifies the interface to apply the filter to and begins interface configuration mode.

Step 3

Filters CLNS traffic going out of the interface, on the basis of the filter specified and named in Step 1.

argument with this command, because ISO CLNS uses access groups but does not use access lists. See the chapters “Configuring a Legacy DDR Spoke” or “Configuring a Legacy DDR Hub” in this publication for more information and examples.

You classify CLNS control packets, including hello packets and routing updates, using the dialer-list protocol clns_is permit and/or dialer-list protocol clns_es permit command.

You can configure ISO CLNS on DDR asynchronous, synchronous serial, and ISDN interfaces, as well as dialer rotary groups.

Configuring XNS Routing

You must enable XNS routing and then define an access list. To define an XNS access list, use one of the following commands in global configuration mode:

Command

Purpose

]]]

or

]]]

Specifies a standard XNS access list.

Specifies an extended XNS access list.

keyword. See the chapters “Configuring a Legacy DDR Spoke” or “Configuring a Legacy DDR Hub” for more information and examples.

You can configure XNS on DDR asynchronous, synchronous serial, and ISDN interfaces, as well as dialer rotary groups.

Associating the Protocol Access List with a Dialer Group

DDR supports the following routed protocols: AppleTalk, Banyan VINES, DECnet, IP, Novell IPX, ISO CLNS, and XNS.

You can permit or deny access by protocol, or you can specify an access list for more refined control. To associate a protocol or access list with a dialer group, use the following command in global configuration mode:

Command

Purpose

}

Associates a protocol access list number or access group name with the dialer group.

Note For a given protocol and a given dialer group, only one access list can be specified in the dialer-list command.

command form, acceptable access list numbers are as follows:

- Banyan VINES, DECnet, IP, and XNS standard and extended access list numbers

- Novell IPX standard, extended, and SAP access list numbers

- AppleTalk access lists numbers

- Bridge type codes

Configuration Examples for Legacy DDR

The following sections provide DDR configuration examples:

- Point-to-Point DDR Without Authentication Examples

- Point-to-Point DDR with Authentication Examples

Point-to-Point DDR Without Authentication Examples

The following example sets up two-way reciprocal DDR without authentication; the client and server have dial-in access to each other. This configuration is demonstrated in the following two subsections.

Remote Configuration

The following sample configuration is performed on the remote side of the connection:

interface ethernet 0

ip address 172.30.44.1 255.255.255.0

!

interface async 7

ip address 172.30.45.2 255.255.255.0

async mode dedicated

peer default ip address 172.30.45.1

encapsulation ppp

dialer in-band

dialer string 1234

dialer-group 1

!

ip route 172.30.43.0 255.255.255.0 async 7

ip default-network 172.30.0.0

chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT

dialer-list 1 protocol ip permit

!

line 7

no exec

modem InOut

speed 38400

flowcontrol hardware

script dialer generic

Local Configuration

The following sample configuration is performed on the local side of the connection:

interface ethernet 0

ip address 172.30.43.1 255.255.255.0

!

interface async 7

async mode dedicated

peer default ip address 172.30.45.2

encapsulation ppp

dialer in-band

dialer string 1235

dialer rotary-group 1

!

interface async 8

async mode dedicated

peer default ip address 172.30.45.2

dialer rotary-group 1

!

ip route 172.30.44.0 255.255.255.0 async 7

ip address 172.30.45.2 255.255.255.0

encapsulation ppp

ppp authentication chap

dialer in-band

dialer map ip 172.30.45.2 name remote 4321

dialer load-threshold 80

!

ip route 172.30.44.0 255.255.255.0 128.150.45.2

chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT

dialer-list 1 protocol ip permit

!

route igrp 109

network 172.30.0.0

redistribute static

passive-interface async 7

!

line 7

modem InOut

speed 38400

flowcontrol hardware

script dialer generic

Point-to-Point DDR with Authentication Examples

The following sample sets up two-way DDR with authentication; the client and server have dial-in access to each other. This configuration is demonstrated in the following two subsections.

Remote Configuration

The following example is performed on the remote side of the connection. It provides authentication by identifying a password that must be provided on each end of the connection.

username local password secret1

username remote password secret2

interface ethernet 0

ip address 172.30.44.1 255.255.255.0

!

interface async 7

ip address 172.30.45.2 255.255.255.0

async mode dedicated

peer default ip address 172.30.45.1

encapsulation ppp

dialer in-band

dialer string 1234

dialer-group 1

!

ip route 172.30.43.0 255.255.255.0 async 7

ip default-network 172.30.0.0

chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT

dialer-list 1 protocol ip permit

!

line 7

no exec

modem InOut

speed 38400

flowcontrol hardware

script dialer generic

Local Configuration

The following example configuration is performed on the local side of the connection. As with the remote side configuration, it provides authentication by identifying a password for each end of the connection.

username remote password secret1

username local password secret2

!

interface ethernet 0

ip address 172.30.43.1 255.255.255.0

!

interface async 7

async mode dedicated

peer default ip address 172.30.45.2

dialer rotary-group 1

!

interface async 8

async mode dedicated

peer default ip address 172.30.45.2

dialer rotary-group 1

!

interface dialer 1

ip address 172.30.45.2 255.255.255.0

encapsulation ppp

ppp authentication chap

dialer in-band

dialer map ip 172.30.45.2 name remote 4321

dialer load-threshold 80

!

ip route 172.30.44.0 255.255.255.0 172.30.45.2

chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT

!

route igrp 109

network 172.30.0.0

redistribute static

passive-interface async 7

!

line 7

modem InOut

speed 38400

flowcontrol hardware

script dialer generic

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007-2009 Cisco Systems, Inc. All rights reserved.

Configuring Legacy DDR Spokes

in a hub-and-spoke network topology. It includes the following main sections:

- DDR Spokes Configuration Task Flow

- How to Configure DDR

- Monitoring DDR Connections

- Configuration Examples for Legacy DDR Spoke

This chapter considers a spoke interface to be any interface that calls or receives calls from exactly one other router, and considers a hub interface to be an interface that calls or receives calls from more than one router: all the spokes in the network.

This chapter also describes the DDR-independent tasks required to bridge protocols or to route protocols over DDR. Most of these tasks are global in scope and can be completed before you begin to configure DDR.

For configuration tasks for the central hub interface in a hub-and-spoke network topology, see the chapter “Configuring a Legacy DDR Hub” in this publication.

For information about the Dialer Profiles implementation of DDR, see the chapter “Configuring Peer-to-Peer DDR with Dialer Profiles” in this publication.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

DDR Spokes Configuration Task Flow

Before you configure DDR, make sure you have completed the preparations for bridging or routing as described in the chapter “Preparing to Configure DDR” in this publication. That chapter provides information about the minimal requirements. For detailed information about bridging, routing, and wide-area networking configurations, refer to the appropriate chapters in other volumes of this documentation set.

When you configure DDR on a spoke interface in a hub-and-spoke topology, you perform the following general steps:

Step 1 Specify the interface that will place calls to or receive calls from a single site. (See the chapter “Configuring Legacy DDR Hubs” in this publication for information about configuring an interface to place calls to or receive calls from multiple sites.)

Step 2 Enable DDR on the interface. This step is not required for some interfaces; for example, ISDN interfaces and passive interfaces that receive only from DTR-dialing interfaces.

Step 3 Configure the interface to receive calls only, if applicable. Receiving calls from multiple sites requires each inbound call to be authenticated.

Step 4 Configure the interface to place calls only, if applicable.

Step 5 Configure the interface to place and receive calls, if applicable.

Step 6 If the interface will place calls, specify access control for:

- Transparent bridging—Assign the interface to a bridge group, and define dialer lists associated with the bridging access lists. The interface switches between members of the same bridge group, and dialer lists specify which packets can trigger calls.

or

- Routed protocols—Define dialer lists associated with the protocol access lists to specify which packets can trigger calls.

Step 7 Customize the interface settings (timers, interface priority, hold queues, bandwidth on demand, and disabling fast switching) as needed.

When you have configured the interface and it is operational, you can monitor its performance and its connections as described in the “Monitoring DDR Connections” section later in this chapter.

You can also enhance DDR by configuring Multilink PPP and configuring PPP callback. The PPP configuration tasks are described in the chapter “Configuring Media-Independent PPP and Multilink PPP” in this publication.

See the section “Configuration Examples for Legacy DDR Spoke” later in this chapter for examples of how to configure DDR on your network.

How to Configure DDR

To configure DDR on an interface, perform the tasks in the following sections. The first five bulleted items are required. The remaining tasks are not required, but might be necessary in your networking environment.

- Specifying the Interface (Required)

- Enabling DDR on the Interface (Required)

- Configuring the Interface to Place Calls (Required)

or

Configuring the Interface to Receive Calls (Required)

or

Configuring the Interface to Place and Receive Calls (Required)

- Defining the Traffic to Be Authenticated (As required)

- Configuring Access Control for Outgoing Calls (As required)

- Configuring Access Control for Bridging (As required)

- Configuring Access Control for Routing (As required)

- Customizing the Interface Settings (As required)

- Sending Traffic over Frame Relay, X.25, or LAPB Networks (As required)

You can also monitor DDR connections. See the “Monitoring DDR Connections” section later in this chapter for commands and other information.

For examples of legacy DDR on a point-to-point connection, see the “Configuration Examples for Legacy DDR Spoke” section later in this chapter.

Specifying the Interface

This section assumes that you have completed any preparatory steps required for the relevant interface. For example, if you intend to use an asynchronous interface, it assumes that you have completed the modem support and line configuration steps and the chat script creation steps. If you intend to use an ISDN interface, it assumes that you have the ISDN line properly provisioned and running.

You can configure any asynchronous, synchronous serial, ISDN, or dialer interface for legacy DDR.

Note When you specify an interface, make sure to use the interface numbering scheme supported on the network interface module or other port hardware on the router. On the Cisco 7200 series, for example, you specify an interface by indicating its type, slot number, and port number.

To specify an interface to configure for DDR, use one of the following commands in global configuration mode:

Command

Purpose

or

or

Specifies an interface to configure for DDR.

Specifies an ISDN PRI D channel (T1).

Specifies an ISDN PRI D channel (E1).

Specifies a logical interface to function as a dialer rotary group leader.

Dialer interfaces are logical or virtual entities, but they use physical interfaces to place or receive calls.

Enabling DDR on the Interface

This task is required for asynchronous or synchronous serial interfaces but not for ISDN interfaces. The software automatically configures ISDN interfaces to be dialer type ISDN.

interfaces that will receive calls only from interfaces that use DTR dialing.

Enabling DDR on an interface usually requires you to specify the type of dialer to be used. This step is not required for ISDN interfaces because the software automatically configures ISDN interfaces to be dialer type ISDN.

To enable DDR and specify the dialer type, use one of the following commands in global configuration mode:

Command

Purpose

or

]

modems using EIA Data Terminal Ready (DTR) signaling.

modems.

Note An interface configured with the dialer in-band command can both place and receive calls. A serial interface configured for DTR dialing can place calls only; it cannot accept them.

command is no parity.

For an example of configuring an interface to support DTR dialing, see the section “DTR Dialing Example” later in this chapter.

To receive calls from an interface that is using DTR dialing, an interface can be configured for in-band dialing or not configured for anything but encapsulation, depending on the desired behavior. If you expect the receiving interface to terminate a call when no traffic is received for some time, you must configure in-band dialing (along with access lists and a dummy dialer string). If the receiving interface is purely passive, no additional configuration is necessary.

Note You can configure an interface or dialer rotary group to both place and receive calls. If the interface is calling and being called by a single site, simply enable DDR and specify a dial string.

Configuring the Interface to Place Calls

To configure an interface to place calls to one site only, perform the tasks in one of the following sections:

- Specifying the Dial String for Synchronous Serial Interfaces (As required)

- Specifying Chat Scripts and Dial Strings for Asynchronous Serial Interfaces (As required)

Specifying the Dial String for Synchronous Serial Interfaces

command. Dialers pass the string you have defined to the external DCE device. ISDN devices call the number specified in the string.

To specify the telephone number call on a serial interface (asynchronous or synchronous), use the following command in interface configuration mode:

Command

Purpose

]

Specifies the number to dial.

Dialers pass the string (telephone number) to the external DCE device, which dials the number; ISDN devices themselves call the specified number.

Specifying Chat Scripts and Dial Strings for Asynchronous Serial Interfaces

commands presented in this section.

To place a call to a single site on an asynchronous line for which either a modem dialing script has not been assigned or a system script login must be specified, use the following command in interface configuration mode:

Command

Purpose

]

Specifies chat scripts and a dial string.

Refer to the sections “How To Configure Chat Scripts” and “Dialer Mapping Example” in the chapter “Creating and Using Modem Chat Scripts” for more information about configuring chat scripts.

Configuring the Interface to Receive Calls

command can terminate calls when the line is idle for some configurable time.

You cannot set up an ISDN interface only to receive calls from a single site, but you can set it up to receive and place calls to a single site.

To receive calls from an interface that is using DTR dialing, an interface can be configured for in-band dialing or not configured for anything but encapsulation, depending on the desired behavior. If you expect the receiving interface to terminate a call when no traffic is received for some time, you must configure in-band dialing (along with access lists and a dummy dialer string). If the receiving interface is purely passive, no additional configuration is necessary.

command shown in that section.

Configuring the Interface to Place and Receive Calls

command, the interface can receive calls. To enable it to place calls to one site, you must define the dialing destination.

To define the dialing destination, use the following command in interface configuration mode:

Command

Purpose

]

Specifies the number to dial one site.

Note Use the dialer map command instead of the dialer string command if you want to authenticate calls received. See the section “Defining the Traffic to Be Authenticated” later in this chapter for more information.

When a dialer string is configured but PPP Challenge Handshake Authentication Protocol (CHAP) is not configured on the interface, the Cisco IOS software recognizes each incoming call as coming from the configured dialer string. That is, if your outgoing calls go to only one number and you do not authenticate incoming calls, it is assumed that all incoming calls come from that number. (If you received calls from multiple sites, you would need to authenticate the calls.)

command.

Defining the Traffic to Be Authenticated

Authentication can be done through CHAP or Password Authentication Protocol (PAP). In addition, the interface must be configured to map the protocol address of the host to the name to use for authenticating the remote host.

To enable CHAP or PAP on an interface and authenticate sites that are calling in, use the following commands in interface configuration mode:

Command

Purpose

Step 1

Configures an interface for PPP encapsulation.

Step 2

]

or

]

Enables CHAP.

Enables PAP.

Step 3

]]

Maps the protocol address to a host name.

If the dial string is not provided in the chat script, the interface will be able to receive calls from the host but will not be able to place calls to the host.

Configuring Access Control for Outgoing Calls

, it will be forwarded if it is intended for a destination known to be on a specific interface and the link is active. However, such a packet will not initiate a DDR call and will not reset the idle timer.

Configuring Access Control for Bridging

of the following tasks in global configuration mode:

- Controlling Bridging Access by Ethernet Type Codes (As required)

- Permitting All Bridge Packets to Trigger Calls (As required)

- Assigning the Interface to a Bridge Group (As required)

Note Spanning-tree bridge protocol data units (BPDUs) are always treated as uninteresting.

Controlling Bridging Access by Ethernet Type Codes

To control access by Ethernet type codes, use the following command in global configuration mode:

Command

Purpose

]

packets by Ethernet type codes (access list numbers must be in the range 200 to 299).

To enable packets with a specified Ethernet type code to trigger outgoing calls, use the following command in interface configuration mode:

Command

Purpose

Defines a dialer list for the specified access list.

Permitting All Bridge Packets to Trigger Calls

To identify all transparent bridge packets as interesting, use the following command in interface configuration mode when you are configuring DDR:

Command

Purpose

.

Assigning the Interface to a Bridge Group

Packets are bridged only among interfaces that belong to the same bridge group. To assign an interface to a bridge group, use the following command in interface configuration mode:

Command

Purpose

Assigns the specified interface to a bridge group.

Configuring Access Control for Routing

).

An interface can be associated only with a single dialer access group; multiple dialer access group assignments are not allowed. To specify the dialer access group to which you want to assign an access list, use the following command in interface configuration mode:

Command

Purpose

Specifies the number of the dialer access group to which the specific interface belongs.

Customizing the Interface Settings

To customize DDR in your network, perform the tasks in the following sections as needed:

- Configuring Timers on the DDR Interface (As required)

- Setting Dialer Interface Priority (As required)

- Configuring a Dialer Hold Queue (As required)

- Configuring Bandwidth on Demand (As required)

- Disabling and Reenabling DDR Fast Switching (As required)

- Configuring Dialer Redial Options (As required)

Configuring Timers on the DDR Interface

To set the timers, perform the tasks in the following sections as needed:

- Setting Line-Idle Time (As required)

- Setting Idle Time for Busy Interfaces (As required)

- Setting Line-Down Time (As required)

- Setting Carrier-Wait Time (As required)

Setting Line-Idle Time

To specify the amount of time for which a line will stay idle before it is disconnected, use the following command in interface configuration mode:

Command

Purpose

]

Specifies the duration of idle time in seconds after which a line will be disconnected.

keyword causes only inbound traffic to reset the timer.

Note The dialer idle-timeout interface configuration command specifies the duration of time before an idle connection is disconnected. Previously, both inbound and outbound traffic would reset the dialer idle timer; now you can specify that only inbound traffic will reset the dialer idle timer.

Setting Idle Time for Busy Interfaces

The dialer fast idle timer is activated if there is contention for a line. Contention occurs when a line is in use, a packet for a different next hop address is received, and the busy line is required to send the competing packet.

If the line has been idle for the configured amount of time, the current call is disconnected immediately and the new call is placed. If the line has not yet been idle as long as the fast idle timeout period, the packet is dropped because there is no way to get through to the destination. (After the packet is dropped, the fast idle timer remains active and the current call is disconnected as soon as it has been idle for as long as the fast idle timeout.) If, in the meantime, another packet is sent to the currently connected destination, and it is classified as interesting, the fast-idle timer is restarted.

To specify the amount of time for which a line for which there is contention will stay idle before the line is disconnected and the competing call is placed, use the following command in interface configuration mode:

Command

Purpose

Sets idle time for high traffic lines.

This command applies to both inbound and outbound calls.

Setting Line-Down Time

To set the length of time for which the interface stays down before it is available to dial again after a line is disconnected or fails, use the following command in interface configuration mode:

Command

Purpose

Sets the interface downtime.

This command applies to both inbound and outbound calls.

Setting Carrier-Wait Time

To set the length of time for which an interface waits for the telephone service (carrier), use the following command in interface configuration mode:

Command

Purpose

Sets the length of time for which the interface waits for the carrier to come up when a call is placed.

For asynchronous interfaces, this command sets the total time to wait for a call to connect. This time is set to allow for running the chat script.

Setting Dialer Interface Priority

Interface priority indicates which interface in a dialer rotary group will get used first for outgoing calls. You might give one interface a higher priority if it is attached to a faster, more reliable modem. In this way, the higher-priority interface will be used as often as possible.

To assign priority to an interface in a dialer rotary group, use the following command in interface configuration mode:

Command

Purpose

Sets the interface priority in the dialer rotary group.

is 0 through 255. Zero is the default value and lowest priority; 255 is the highest priority. This command applies to outgoing calls only.

Configuring a Dialer Hold Queue

outgoing packets to be queued and sent as soon as the modem connection is established.

can be configured with a dialer hold queue. If a hunt group leader (of a rotary dialing group) is configured with a hold queue, all members of the group will be configured with a dialer hold queue and no hold queue of an individual member can be altered.

To establish a dialer hold queue, use the following command in interface configuration mode:

Command

Purpose

Creates a dialer hold queue and specifies the number of packets to be held in it.

As many as 100 packets can be held in an outgoing dialer hold queue.

Configuring Bandwidth on Demand

You can configure a dialer rotary group to use additional bandwidth by placing additional calls to a single destination if the load for the interface exceeds a specified weighted value. Parallel communication links are established based on traffic load. The number of parallel links that can be established to one location is not limited.

To set the dialer load threshold for bandwidth on demand, use the following command in interface configuration mode:

Command

Purpose

Configures the dialer rotary group to place additional calls to a single destination, as indicated by interface load.

Once multiple links are established, they are still governed by the load threshold. If the total load on all the links falls below the threshold, an idle link will be torn down.

Disabling and Reenabling DDR Fast Switching

Fast switching is enabled by default on all DDR interfaces. When fast switching is enabled or disabled on an ISDN D channel, it is enabled or disabled on all B channels. When fast switching is enabled or disabled on a dialer interface, it is enabled or disabled on all rotary group members but cannot be enabled or disabled on the serial interfaces individually.

Fast switching can be disabled and re-enabled on a protocol-by-protocol basis. To disable fast switching and re-enable it, use one of the following protocol-specific commands in interface configuration mode:

Command

Purpose

Disables IP fast switching over a DDR interface.

Reenables IP fast switching over a DDR interface.

Disables distributed IP fast switching over a DDR interface. This feature works in Cisco 7500 routers with a Versatile Interface Processor (VIP) card.

Enables distributed IP fast switching over a DDR interface. This feature works in Cisco 7500 routers with a VIP card.

Disables IPX fast switching over a DDR interface.

Reenables IPX fast switching over a DDR interface.

Configuring Dialer Redial Options

By default, the Cisco IOS software generates a single dial attempt for each interesting packet. Dialer redial allows the dialer to be configured to make a maximum number of redial attempts if the first dial-out attempt fails, wait a specific interval between redial attempts, and disable the interface for a specified duration if all redial attempts fail. New dialout attempts will not be initiated if a redial is pending to the same destination.

To configure redial options, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Enters interface configuration mode.

Step 2

Configures redial options on the router.

Sending Traffic over Frame Relay, X.25, or LAPB Networks

An interface configured for DDR can send traffic over networks that require Link Access Procedure, Balanced (LAPB), X.25, or Frame Relay encapsulation.

Before Cisco IOS software Release 12.0(6)T, encapsulation techniques such as Frame Relay, HDLC, LAPB-TA, and X.25 could support only one ISDN B-channel connection over the entire link. HDLC and PPP could support multiple B channels, but the entire ISDN link needed to use the same encapsulation. The Dynamic Multiple Encapsulations feature allows incoming calls over ISDN to be assigned encapsulation type based on calling line identification (CLID) or DNIS. With the Dynamic Multiple Encapsulations feature, once CLID binding is completed, the topmost interface is always used for all configuration and data structures. The ISDN B channel becomes a forwarding device, and the configuration on the D channel is ignored, thereby allowing the different encapsulation types and per-user configurations.

To configure an interface for those networks, perform the tasks in the following sections:

- Configuring the Interface for Sending Traffic over a Frame Relay Network (As required)

- Configuring the Interface for Sending Traffic over an X.25 Network (As required)

- Configuring the Interface for Sending Traffic over a LAPB Network (As required)

Configuring the Interface for Sending Traffic over a Frame Relay Network

Access to Frame Relay networks is now available through dialup connections as well as leased lines. Dialup connectivity allows Frame Relay networks to be extended to sites that do not generate enough traffic to justify leased lines, and also allows a Frame Relay network to back up another network or point-to-point line.

DDR over Frame Relay is supported for synchronous serial and ISDN interfaces and for rotary groups, and is available for in-band, DTR, and ISDN dialers.

interface can be used (dialed, connected, and active) in a rotary group or with ISDN.

The Dynamic Multiple Encapsulations feature supports the following Frame Relay features:

- Frame Relay RTP Header Compression (RFC 1889)

- Frame Relay TCP/IP Header Compression

- Legacy DDR over Frame Relay

- Frame Relay Interface/Subinterface Backup

Dynamic multiple encapsulations support at least four Frame Relay PVCs on either dialer interfaces or dialer subinterfaces.

Note Frame Relay encapsulations in the Dynamic Multiple Encapsulations feature do not support IETF or Cisco Encapsulation for IBM Systems Network Architecture (SNA). Frame Relay for SNA support is not applicable.

Configuration Restrictions

The following restrictions apply to DDR used over Frame Relay:

- Frame Relay is not available for asynchronous dialers.

- The Frame Relay Dynamic Multiple Encapsulations feature does not provide bidirectional support.

- With the Dynamic Multiple Encapsulations feature, there is no process switching for Frame Relay packets; these packets are always fast switched.

- Like HDLC, LAPB, and X.25, Frame Relay does not provide authentication. However, ISDN dialers can offer some authentication through the caller ID feature.

- Only one ISDN B channel can be dialed at any one time. When configuring a rotary group, you can use only one serial interface.

Frame Relay subinterfaces work the same on dialup connections as they do on leased lines.

Configuration Overview

No new commands are required to support DDR over Frame Relay. In general, you configure Frame Relay and configure DDR. In general, complete the following tasks to configure an interface for DDR over Frame Relay:

- Specify the interface.

- Specify the protocol identifiers for the interface.

For example, enter the IP address and mask, the IPX network number, and the AppleTalk cable range and zone.

- Configure Frame Relay.

As a minimum, you must enable Frame Relay encapsulation and decide whether you need to do static or dynamic address mapping. If you decide to do dynamic mapping, you need not enter a command because Inverse Address Resolution Protocol is enabled by default. If you decide to do static mapping, you must enter Frame Relay mapping commands.

You can then configure various options as needed for your Frame Relay network topology.

- Configure DDR.

At a minimum, you must decide and configure the interface for outgoing calls only, incoming calls only, or both outgoing and incoming calls.

You can also configure DDR for your routed protocols (as specified in the section “Preparations for Routing or Bridging over DDR” in the chapter “Preparing to Configure DDR” in this publication) and for snapshot routing (as specified in the chapter “Configuring Snapshot Routing” later in this publication). You can also customize DDR interfaces on your router or access server (as described in the section “Customizing the Interface Settings” in this chapter).

For examples of configuring various interfaces for DDR over Frame Relay, see the section “Frame Relay Support Example” later in this chapter.

Configuring the Interface for Sending Traffic over an X.25 Network

X.25 interfaces can now be configured to support DDR. Synchronous serial and ISDN interfaces on Cisco routers and access servers can be configured for X.25 addresses, X.25 encapsulation, and mapping of protocol addresses to the X.25 address of a remote host. In-band, DTR, and ISDN dialers can be configured to support X.25 encapsulation, but rotary groups cannot.

Remember that for ISDN interfaces, once CLID binding is completed, the topmost interface is always used for all configuration and data structures. The ISDN B channel becomes a forwarding device, and the configuration on the D channel is ignored, thereby allowing the different encapsulation types and per-user configurations. For X.25 encapsulations, the configurations reside on the dialer profile. The Dynamic Multiple Encapsulations feature provides support for packet assembler/disassembler (PAD) traffic and X.25 encapsulated and switched packets.

To configure an interface to support X.25 and DDR, use the following X.25-specific commands in interface configuration mode:

Command

Purpose

Step 1

Configures the interface to use X.25 encapsulation.

Step 2

Assigns an X.25 address to the interface.

Step 3

]

Sets up the LAN protocols-to-remote host address mapping.

The order of DDR and X.25 configuration tasks is not critical; you can configure DDR before or after X.25, and you can even mix the DDR and X.25 commands.

For an example of configuring an interface for X.25 encapsulation and then completing the DDR configuration, see the section “X.25 Support Example” later in this chapter.

Configuring the Interface for Sending Traffic over a LAPB Network

DDR over serial lines now supports LAPB encapsulation, in addition to the previously supported PPP, HDLC, and X.25 encapsulations.

LAPB encapsulation is supported on synchronous serial, ISDN, and dialer rotary group interfaces, but not on asynchronous dialers.

Because the default encapsulation is HDLC, you must explicitly configure LAPB encapsulation. To configure an interface to support LAPB encapsulation and DDR, use the following command in interface configuration mode:

Command

Purpose

]

Specifies LAPB encapsulation.

For an example of configuring an interface for DDR over LAPB, see the section “LAPB Support Example” later in this chapter.

Monitoring DDR Connections

To monitor DDR connections, use any of the following commands in privileged EXEC mode:

Command

Purpose

]

Displays general diagnostics about the DDR interface.

Displays current dialer maps, next-hop protocol addresses, user names, and the interfaces on which they are configured.

Displays information about the ISDN interface.

]

Displays status about the IPX interface.

Displays information about the IPX packets sent by the router or access server, including watchdog counters.

Displays information about the AppleTalk packets sent by the router or access server.

Displays information about the Banyan VINES packets sent by the router or access server.

Displays information about the DECnet packets sent by the router or access server.

Displays information about the XNS packets sent by the router or access server.

Clears the values of the general diagnostic statistics.

Configuration Examples for Legacy DDR Spoke

The following section provides various DDR configurations examples:

- Legacy Dial-on-Demand Routing Example

- Transparent Bridging over DDR Examples

- DDR Configuration in an IP Environment Example

- Two-Way DDR for Novell IPX Example

- AppleTalk Configuration Example

- DECnet Configuration Example

- ISO CLNS Configuration Example

- XNS Configuration Example

- Single Site Dialing Example

- DTR Dialing Example

- Hub-and-Spoke DDR for Asynchronous Interfaces and Authentication Example

- Two-Way Reciprocal Client/Server DDR Without Authentication Example

- Frame Relay Support Example

- X.25 Support Example

- LAPB Support Example

Legacy Dial-on-Demand Routing Example

keyword. This command allows only inbound traffic that conforms to the dialer list to establish a connection and reset the dialer idle timer.

interface BRI0/0

ip address 10.1.1.1 255.255.255.0

no ip directed-broadcast

encapsulation ppp

dialer idle-timeout 120 inbound

dialer map ip 10.1.1.2 name 2611-7 0201

dialer-group 1

isdn switch-type basic-5ess

no cdp enable

ppp authentication chap

!

ip classless

ip route 10.2.1.1 255.255.255.255 10.1.1.2

!

access-list 101 permit icmp any any

access-list 101 deny ip any any

dialer-list 1 protocol ip list 101

tftp-server flash c2600-i-mz.jtong-CSCdm88145-120

Transparent Bridging over DDR Examples

The following two examples differ only in the packets that cause calls to be placed. The first example specifies by protocol (any bridge packet is permitted to cause a call to be made); the second example allows a finer granularity by specifying the Ethernet type codes of bridge packets.

The first example configures the serial 1 interface for DDR bridging. Any bridge packet is permitted to cause a call to be placed.

no ip routing

!

interface Serial1

no ip address

encapsulation ppp

dialer in-band

dialer enable-timeout 3

dialer map bridge name urk broadcast 8985

dialer hold-queue 10

dialer-group 1

ppp authentication chap

bridge-group 1

pulse-time 1

!

dialer-list 1 protocol bridge permit

bridge 1 protocol ieee

bridge 1 hello 10

command that refers to the specified access list.

no ip routing

!

interface Serial1

no ip address

encapsulation ppp

dialer in-band

dialer enable-timeout 3

dialer map bridge name urk broadcast 8985

dialer hold-queue 10

dialer-group 1

ppp authentication chap

bridge-group 1

pulse-time 1

!

access-list 200 permit 0x0800 0xFFF8

!

dialer-list 1 protocol bridge list 200

bridge 1 protocol ieee

bridge 1 hello 10

DDR Configuration in an IP Environment Example

The following example illustrates how to use DDR on an synchronous interface in an IP environment. You could use the same configuration on an asynchronous serial interface by changing interface serial 1 to specify an asynchronous interface (for example, interface async 0).

interface serial 1

ip address 172.18.126.1 255.255.255.0

dialer in-band

! The next command sets the dialer idle time-out to 10 minutes.

dialer idle-timeout 600

! The next command inserts the phone number.

dialer string 5551234

! The next command gives the modem enough time to recognize that

! DTR has dropped so the modem disconnects the call.

pulse-time 1

! The next command adds this interface to the dialer access group defined with

! the dialer-list command.

dialer-group 1

!

! The first access list statement, below, specifies that IGRP updates are not

! interesting packets. The second access-list statement specifies that all

! other IP traffic such as Ping, Telnet, or any other IP packet are interesting

! packets. The dialer-list command then creates dialer access group 1 and states

! that access list 101 is to be used to classify packets as interesting or

! uninteresting. The ip route commands specify that there is a route to network

! 172.18.29.0 and to network 172.18.1.0 via 131.108.126.2. This means that several

! destination networks are available through a router that is dialed from interface

! async 1.

!

access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

dialer-list 1 list 101

ip route 172.18.29.0 172.18.126.2

ip route 172.18.1.0 172.18.126.2

ip local pool dialin 10.102.126.2 10.102.126.254

command must be used so that DTR is dropped for enough time to allow the modem to disconnect.

. Without this command, static routes to the hosts or network that the router can access with DDR will not be advertised to other routers with which the router is communicating. This behavior can block communication because some routes will not be known.

Two-Way DDR for Novell IPX Example

You can set DDR for Novell IPX so that both the client and server have dial-in access to each other. This configuration is demonstrated in the following two subsections.

Remote Configuration Example

The following example is performed on the remote side of the connection:

username local password secret

ipx routing

!

interface ethernet 0

ipx network 40

!

interface async

ip unnumbered e0

encapsulation ppp

async mode dedicated

async dynamic routing

ipx network 45

ipx watchdog-spoof

dialer in-band

dialer map ipx 45.0000.0cff.d016 broadcast name local 1212

dialer-group 1

ppp authentication chap

!

access-list 901 deny 0 FFFFFFFF 452

access-list 901 deny 0 FFFFFFFF 453

access-list 901 deny 0 FFFFFFFF 457

access-list 901 deny 0 FFFFFFFF 0 FFFFFFFF 452

access-list 901 deny 0 FFFFFFFF 0 FFFFFFFF 453

access-list 901 deny 0 FFFFFFFF 0 FFFFFFFF 457

access-list 901 permit 0

ipx route 41 45.0000.0cff.d016

ipx route 50 45.0000.0cff.d016

ipx sap 4 SERVER 50.0000.0000.0001 451 2

chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT

!

dialer-list 1 list 901

!

line 7

modem InOut

speed 38400

flowcontrol hardware

modem chat-script generic

Local Configuration Example

The following example is performed on the local side of the connection:

username remote password secret

ipx routing

!

interface ethernet 0

ipx network 41

!

interface async

ip unnumbered e0

encapsulation ppp

async mode dedicated

async dynamic routing

ipx network 45

ipx watchdog-spoof

dialer in-band

dialer map ipx 45.0000.0cff.d016 broadcast name remote 8888

dialer-group 1

ppp authentication chap

!

access-list 901 deny 0 FFFFFFFF 452

access-list 901 deny 0 FFFFFFFF 453

access-list 901 deny 0 FFFFFFFF 457

access-list 901 deny 0 FFFFFFFF 0 FFFFFFFF 452

access-list 901 deny 0 FFFFFFFF 0 FFFFFFFF 453

access-list 901 deny 0 FFFFFFFF 0 FFFFFFFF 457

access-list 901 permit 0

ipx route 40 45.0000.0cff.d016

chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT

!

dialer-list 1 list 901

!

line 7

modem InOut

speed 38400

flowcontrol hardware

modem chat-script generic

AppleTalk Configuration Example

The following example configures DDR for AppleTalk access using an ISDN BRI. Two access lists are defined: one for IP and Interior Gateway Routing Protocol (IGRP) and one for AppleTalk. AppleTalk packets from network 2141 only (except broadcast packets) can initiate calls.

interface BRI0

ip address 172.17.20.107 255.255.255.0

encapsulation ppp

appletalk cable-range 2141-2141 2141.65

appletalk zone SCruz-Eng

no appletalk send-rtmps

dialer map ip 172.17.20.106 broadcast 1879

dialer map appletalk 2141.66 broadcast 1879

dialer-group 1

!

access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

access-list 601 permit cable-range 2141-2141 broadcast-deny

access-list 601 deny other-access

!

dialer-list 1 list 101

dialer-list 1 list 601

DECnet Configuration Example

The following example configures DDR for DECnet:

decnet routing 10.19

username RouterB password 7 030752180531

interface serial 0

no ip address

decnet cost 10

encapsulation ppp

dialer in-band

dialer map decnet 10.151 name RouterB broadcast 4155551212

dialer-group 1

ppp authentication chap

pulse-time 1

access-list 301 permit 10.0 0.1023 0.0 63.1023

dialer-list 1 protocol decnet list 301

ISO CLNS Configuration Example

The following example configures a router for International Organization for Standardization Connectionless Network Service (ISO CLNS) DDR with in-band dialing:

username RouterB password 7 111C140B0E

clns net 47.0004.0001.0000.0c00.2222.00

clns routing

clns filter-set ddrline permit 47.0004.0001....

!

interface serial 0

no ip address

encapsulation ppp

dialer in-band

dialer map clns 47.0004.0001.0000.0c00.1111.00 name RouterB broadcast 1212

dialer-group 1

ppp authentication chap

clns enable

pulse-time 1

!

clns route default serial 0

dialer-list 1 protocol clns list ddrline

XNS Configuration Example

The following example configures DDR for XNS. The access lists deny broadcast traffic to any host on any network, but allow all other traffic.

xns routing 0000.0c01.d8dd

username RouterB password 7 111B210A0F

interface serial 0

no ip address

encapsulation ppp

xns network 10

dialer in-band

dialer map xns 10.0000.0c01.d877 name RouterB broadcast 4155551212

dialer-group 1

ppp authentication chap

pulse-time 1

!

access-list 400 deny -1 -1.ffff.ffff.ffff 0000.0000.0000

access-list 400 permit -1 10

!

dialer-list 1 protocol xns list 400

Single Site Dialing Example

The following example is based on the configuration shown in Figure 1; the router receives a packet with a next hop address of 10.1.1.1.

Figure 1 Sample Dialer String or Dialer Map Configuration

command is used to specify the string (telephone number) to be called.

interface serial 1

dialer in-band

dialer string 5555555

DTR Dialing Example

The following example shows Router A and Router B connected to a Public Switched Telephone Network (PSTN). Router A is configured for DTR dialing. Remote Router B is configured for in-band dialing so it can disconnect an idle call. (See Figure 2.)

Figure 2 DTR Dialing Through a PSTN

Router A

interface serial 0

ip address 172.18.170.19 255.255.255.0

dialer dtr

dialer-group 1

!

access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

!

dialer-list 1 list 101

Router B

interface serial 0

ip address 172.18.170.20 255.255.255.0

dialer in-band

dialer string 9876543

pulse-time 1

!

access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

!

dialer-list 1 list 101

Hub-and-Spoke DDR for Asynchronous Interfaces and Authentication Example

The following example sets up DDR to provide service to multiple remote sites. In a hub-and-spoke configuration, you can use a generic configuration script to set up each remote connection. Figure 3 illustrates a typical hub-and-spoke configuration.

Figure 3 Hub-and-Spoke DDR Configuration

Commands in the following sections are used to create this configuration.

Spoke Topology Configuration

The following commands are executed on the spoke side of the connection. (A different “spoke” password must be specified for each remote client.) The configuration provides authentication by identifying a password that must be provided on each end of the connection.

interface ethernet 0

ip address 172.30.44.1 255.255.255.0

!

interface async 7

async mode dedicated

async default ip address 172.30.45.1

ip address 172.30.45.2 255.255.255.0

encapsulation ppp

ppp authentication chap

dialer in-band

dialer map ip 172.30.45.1 name hub system-script hub 1234

dialer map ip 172.30.45.255 name hub system-script hub 1234

dialer-group 1

!

ip route 172.30.43.0 255.255.255.0 172.30.45.1

ip default-network 172.30.0.0

chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT

chat-script hub ““ ““ name: spoke1 word: <spoke1-passwd> PPP

dialer-list 1 protocol ip permit

!

username hub password <spoke1-passwd>

!

router igrp 109

network 172.30.0.0

passive-interface async 7

!

line 7

modem InOut

speed 38400

flowcontrol hardware

modem chat-script generic

Hub Router Configuration

The following commands are executed on the local side of the connection—the hub router. The commands configure the server for communication with three clients and provide authentication by identifying a unique password for each “spoke” in the hub-and-spoke configuration.

interface ethernet 0

ip address 172.30.43.1 255.255.255.0

!

interface async 7

async mode interactive

async dynamic address

dialer rotary-group 1

!

interface async 8

async mode interactive

async dynamic address

dialer rotary-group 1

!

interface dialer 1

ip address 172.30.45.2 255.255.255.0

no ip split-horizon

encapsulation ppp

ppp authentication chap

dialer in-band

dialer map ip 172.30.45.2 name spoke1 3333

dialer map ip 172.30.45.2 name spoke2 4444

dialer map ip 172.30.45.2 name spoke3 5555

dialer map ip 172.30.45.255 name spoke1 3333

dialer map ip 172.30.45.255 name spoke2 4444

dialer map ip 172.30.45.255 name spoke3 5555

dialer-group 1

!

ip route 172.30.44.0 255.255.255.0 172.30.45.2

ip route 172.30.44.0 255.255.255.0 172.30.45.3

ip route 172.30.44.0 255.255.255.0 172.30.45.4

dialer-list 1 list 101

access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT

!

username spoke1 password <spoke1-passwd>

username spoke2 password <spoke2-passwd>

username spoke3 password <spoke3-passwd>

username spoke1 autocommand ppp 172.30.45.2

username spoke2 autocommand ppp 172.30.45.3

username spoke3 autocommand ppp 172.30.45.4

!

router igrp 109

network 172.30.0.0

redistribute static

!

line 7

login tacacs

modem InOut

speed 38400

flowcontrol hardware

modem chat-script generic

Two-Way Reciprocal Client/Server DDR Without Authentication Example

You can set up two-way reciprocal DDR without authentication in which both the client and server have dial-in access to each other. This configuration is demonstrated in the following two sections.

Remote Configuration

The following commands are executed on the remote side of the connection. This configuration provides authentication by identifying a password that must be provided on each end of the connection.

interface ethernet 0

ip address 172.30.44.1 255.255.255.0

!

interface async 7

ip address 172.30.45.2 255.255.255.0

async mode dedicated

async default ip address 172.30.45.1

encap ppp

dialer in-band

dialer string 1234

dialer-group 1

!

ip route 172.30.43.0 255.255.255.0 async 7

ip default-network 172.30.0.0

chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT

dialer-list 1 protocol ip permit

!

line 7

no exec

modem InOut

speed 38400

flowcontrol hardware

modem chat-script generic

Local Configuration

The following commands are executed on the local side of the connection. As with the remote side configuration, this configuration provides authentication by identifying a password for each end of the connection.

interface ethernet 0

ip address 172.30.43.1 255.255.255.0

!

interface async 7

async mode dedicated

async default ip address 172.30.45.2

encapsulation ppp

dialer in-band

dialer string 1235

dialer rotary-group 1

!

interface async 8

async mode dedicated

async default ip address 172.30.45.2

dialer rotary-group 1

!

ip route 172.30.44.0 255.255.255.0 async 7

ip address 172.30.45.2 255.255.255.0

encapsulation ppp

ppp authentication chap

dialer in-band

dialer map ip 172.30.45.2 name remote 4321

dialer load-threshold 80

!

ip route 172.30.44.0 255.255.255.0 128.150.45.2

chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT

dialer-list 1 protocol ip permit

!

route igrp 109

network 172.30.0.0

redistribute static

passive-interface async 7

!

line 7

modem InOut

speed 38400

flowcontrol hardware

modem chat-script generic

Frame Relay Support Example

The examples in this section present various combinations of interfaces, Frame Relay features, and DDR features.

Frame Relay Access with In-Band Dialing (V.25 bis ) and Static Mapping Example

The following example shows how to configure a router for IP over Frame Relay using in-band dialing. A Frame Relay static map is used to associate the next hop protocol address to the data-link connection identifier (DLCI). The dialer string allows dialing to only one destination.

interface Serial0

ip address 10.1.1.1 255.255.255.0

encapsulation frame-relay

frame-relay map ip 10.1.1.2 100 broadcast

dialer in-band

dialer string 4155551212

dialer-group 1

!

access-list 101 deny igrp any host 255.255.255.255

access-list 101 permit ip any any

!

dialer-list 1 protocol ip list 101

Frame Relay Access with ISDN Dialing and DDR Dynamic Maps Example

The following example shows a BRI interface configured for Frame Relay and for IP, IPX, and AppleTalk routing. No static maps are defined because this setup relies on Frame Relay Local Management Interface (LMI) signaling and Inverse ARP to determine the network addresses-to-DLCI mappings dynamically. (Because Frame Relay Inverse ARP is enabled by default, no command is required.)

interface BRI0

ip address 10.1.1.1 255.255.255.0

ipx network 100

appletalk cable-range 100-100 100.1

appletalk zone ISDN

no appletalk send-rtmps

encapsulation frame-relay IETF

dialer map ip 10.1.1.2 broadcast 4155551212

dialer map apple 100.2 broadcast 4155551212

dialer map ipx 100.0000.0c05.33ed broadcast 4085551234

dialer-group 1

!

access-list 101 deny igrp any host 255.255.255.255

access-list 101 permit ip any any

access-list 901 deny -1 FFFFFFFF 452

access-list 901 deny -1 FFFFFFFF 453

access-list 901 deny -1 FFFFFFFF 457

access-list 901 deny -1 FFFFFFFF 0 FFFFFFFF 452

access-list 901 deny -1 FFFFFFFF 0 FFFFFFFF 453

access-list 901 deny -1 FFFFFFFF 0 FFFFFFFF 457

access-list 901 permit -1

access-list 601 permit cable-range 100-100 broadcast-deny

access-list 601 deny other-access

!

dialer-list 1 protocol ip list 101

dialer-list 1 protocol novell list 901

dialer-list 1 protocol apple list 601

X.25 Support Example

The following example configures a router to support X.25 and DTR dialing:

interface serial 0

ip address 172.18.170.19 255.255.255.0

encapsulation x25

x25 address 12345

x25 map ip 172.18.171.20 67890 broadcast

dialer dtr

dialer-group 1

!

access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

!

dialer-list 1 list 101

LAPB Support Example

The following example configures a router for LAPB encapsulation and in-band dialing:

interface serial 0

ip address 172.18.170.19 255.255.255.0

encapsulation lapb

dialer in-band

dialer string 4155551212

dialer-group 1

!

access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

!

dialer-list 1 protocol ip list 101

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001-2009 Cisco Systems, Inc. All rights reserved.

Configuring Legacy DDR Hubs

This chapter describes how to configure legacy dial-on-demand routing (DDR) on interfaces functioning as the hub in a hub-and-spoke network topology. It includes the following main sections:

- DDR Issues

- DDR Hubs Configuration Task Flow

- How to Configure DDR

- Monitoring DDR Connections

- Configuration Examples for Legacy DDR Hub

interface to be an interface that calls or receives calls from exactly one router.

For configuration tasks for the spoke interfaces in a hub-and-spoke network topology, see the chapter “Configuring Legacy DDR Spokes” in this publication.

For information about the dialer profiles implementation of DDR, see the chapter “Configuring Peer-to-Peer DDR with Dialer Profiles” in this publication.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

, Release 12.2. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

DDR Issues

A DDR configuration applies to a specified router interface but serves to meet the communication needs of the network. The router configured for DDR has a function to serve in preserving communications and ensuring that routes are known to other routers at both ends of the dial link. Thus, these issues are important:

- Types and number of router interfaces to be configured for DDR.

- Function of each specific interface—to place calls, receive calls, or both—and the number of sites connecting to the interface.

- Identity and characteristics of the router at the other end of each connection—phone number, host name, next hop network protocol addresses, type of signaling used or required, ability to place or receive calls, other requirements.

- Types of packets that will be allowed to trigger outgoing calls—if the interface places calls.

- End of the connection that will control the communication: initiating calls and terminating calls when the line is idle.

- Method for authenticating other routers—if the interface receives calls from multiple sites.

- Passing routing information across the dial link.

DDR Hubs Configuration Task Flow

Before you configure DDR, make sure you have completed the preparations for bridging or routing as described in the chapter “Preparing to Configure DDR” in this publication. That chapter provides information about the minimal requirements. For detailed information about bridging, routing, and wide-area networking configurations, see the appropriate chapters in other volumes of this documentation set.

When you configure DDR on a hub interface in a hub-and-spoke topology, you perform the following general steps:

Step 1 Specify the interface that will place calls to or receive calls from multiple sites. (See the chapter “Configuring Legacy DDR Spokes” in this publication for information about configuring an interface to place calls to or receive calls from one site only.)

Step 2 Enable DDR on the interface. This step is not required for some interfaces; for example, ISDN interfaces and passive interfaces that receive only from data terminal ready (DTR)-dialing interfaces.

Step 3 Configure the interface to receive calls only, if applicable. Receiving calls from multiple sites requires each inbound call to be authenticated.

Step 4 Configure the interface to place calls only, if applicable.

Step 5 Configure the interface to place and receive calls, if applicable.

Step 6 If the interface will place calls, specify access control for the following:

- Transparent bridging—Assign the interface to a bridge group, and define dialer lists associated with the bridging access lists. The interface switches between members of the same bridge group, and dialer lists specify which packets can trigger calls.

or

- Routed protocols—Define dialer lists associated with the protocol access lists to specify which packets can trigger calls.

Step 7 Customize the interface settings (timers, interface priority, hold queues, bandwidth on demand, and disabling fast switching) as needed.

When you have configured the interface and it is operational, you can monitor its performance and its connections as described in the “Monitoring DDR Connections” section later in this chapter.

You can also enhance DDR by configuring Multilink PPP and configuring PPP callback. The PPP configuration tasks are described in the chapter “Configuring Media-Independent PPP and Multilink PPP” in this publication.

See the section “Configuration Examples for Legacy DDR Hub” at the end of this chapter for examples of how to configure DDR on your network.

How to Configure DDR

To configure DDR on an interface, perform the tasks in the following sections. The first five bulleted items are required. The remaining tasks are not absolutely required, but might be necessary in your networking environment.

- Specifying the Interface (Required)

- Enabling DDR on the Interface (Required)

- Configuring the Interface to Place Calls Only (Required)

or

Configuring the Interface to Receive Calls Only (Required)

or

Configuring the Interface to Place and Receive Calls (Required)

- Configuring Access Control for Outgoing Calls (As required)

- Customizing the Interface Settings (As required)

- Sending Traffic over Frame Relay, X.25, or LAPB Networks (As required)

See the section “Monitoring DDR Connections” later in this chapter for commands and other information about monitoring DDR connections. See the section “Configuration Examples for Legacy DDR Hub” at the end of this chapter for ideas about how to implement DDR in your network.

Specifying the Interface

You can configure any asynchronous, synchronous serial, ISDN, or dialer interface for legacy DDR.

Note When you specify an interface, make sure to use the interface numbering scheme supported on the network interface module or other port hardware on the router. On the Cisco 7200 series router, for example, you specify an interface by indicating its type, slot number, and port number.

To specify an interface to configure for DDR, use one of the following commands in global configuration mode:

Command

Purpose

or

or

Specifies an interface to configure for DDR.

Specifies an ISDN PRI D channel (T1).

Specifies an ISDN PRI D channel (E1).

Specifies a logical interface to function as a dialer rotary group leader.

Dialer interfaces are logical or virtual entities, but they use physical interfaces to place or receive calls.

Enabling DDR on the Interface

This task is required for asynchronous serial, synchronous serial, and logical dialer interfaces.

interfaces that will receive calls only from interfaces that use DTR dialing.

Enabling DDR on an interface usually requires you to specify the type of dialer to be used. This task is not required for ISDN interfaces because the software automatically configures ISDN interfaces to be dialer type ISDN.

To enable DDR on the interface, use the following command in interface configuration mode:

Command

Purpose

]

modems.

command is no parity.

Configuring the Interface to Place Calls Only

To configure an interface to place calls to multiple destinations, perform the following tasks. The first task is required for all interface types. The second task is required only if you specified a dialer interface.

- Defining the Dialing Destination (Required)

- Specifying a Physical Interface to Use and Assigning It to a Dialer Rotary Group (As required)

Defining the Dialing Destination

For calling multiple sites, an interface or dialer rotary group must be configured to map each next hop protocol address to the dial string (some form of a telephone number) used to reach it.

To define each dialing destination, use one of the following commands in interface configuration mode:

Command

Purpose

]

Defines a dialing destination for a synchronous serial interface or a dialer interface.

]]

Defines a dialing destination for an ISDN interface (including an ISDN PRI D channel).

]

Defines a dialing destination for an asynchronous interface.

If a modem dialing chat script has not been assigned to the line or a system login chat script must be specified, defines both a dialing destination and the chat scripts to use.

Repeat this task as many times as needed to ensure that all dialing destinations are reachable via some next hop address and dialed number.

If you intend to send traffic over other types of networks, see one of the following sections later in this chapter: “Configuring the Interface for Sending Traffic over a Frame Relay Network,” “Configuring the Interface for Sending Traffic over an X.25 Network,” or “Configuring the Interface for Sending Traffic over a LAPB Network.”

Specifying a Physical Interface to Use and Assigning It to a Dialer Rotary Group

This section applies only if you specified a dialer interface to configure for DDR.

To assign a physical interface to a dialer rotary group, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

or

Specifies a physical interface to use and begins interface configuration mode.

Step 2

Assigns the specified physical interface to a dialer rotary group.

Repeat these two steps for each physical interface to be used by the dialer interface.

An ISDN BRI is a rotary group of B channels. An ISDN interface can be part of a rotary group comprising other interfaces (synchronous, asynchronous, ISDN BRI, or ISDN PRI). However, Cisco supports at most one level of recursion; that is, a rotary of rotaries is acceptable, but a rotary of rotaries of rotaries is not supported.

Interfaces in a dialer rotary group do not have individual addresses; when the interface is being used for dialing, it inherits the parameters configured for the dialer interface. However, if the individual interface is configured with an address and it is subsequently used to establish a connection from the user EXEC level, the individual interface address again applies.

Note When you look at your configuration file, commands will not appear in the order in which you entered them. You will also see interface configuration commands that you did not enter, because each interface assigned to a dialer rotary group inherits the parameters of the dialer interface in the dialer rotary group.

Figure 1 illustrates how dialer interfaces work. In this configuration, serial interfaces 1, 2, and 3 are assigned to dialer rotary group 1 and thereby take on the parameters configured for dialer interface 1. When it is used for dialing, the IP address of serial interface 2 is the same as the address of the dialer interface, 172.18.1.1.

Figure 1 Sample Dialer Interface Configuration

Configuring the Interface to Receive Calls Only

Once DDR is enabled on an asynchronous serial, synchronous serial, and ISDN interface, the interface can receive calls from multiple sites using one line or multiple lines. However, interfaces that receive calls from multiple sites require authentication of the remote sites. In addition, dialer interfaces require at least one physical interface to be specified and added to the dialer rotary group. The tasks in the following sections describe how to configuration authentication:

- Configuring the Interface for TACACS+

or

- Configuring the Interface for PPP Authentication

- Specifying Physical Interfaces and Assigning Them to the Dialer Rotary Group

Configuring the Interface for TACACS+

To configure TACACS as an alternative to host authentication, use one of the following commands in interface configuration mode:

Command

Purpose

or

Configures TACACS.

command with authentication, authorization, and accounting (AAA)/TACACS+.

Configuring the Interface for PPP Authentication

This section specifies the minimum required configuration for PPP Challenge Handshake Authentication Protocol (CHAP) or Password Authentication Protocol (PAP) authentication. For more detailed information, see the chapter “Configuring Media-Independent PPP and Multilink PPP” in this publication.

To use CHAP or PAP authentication, perform the following steps beginning in interface configuration mode:

Note After you have enabled one of these protocols, the local router or access server requires authentication of the remote devices that are calling. If the remote device does not support the enabled authentication protocol, no traffic will be passed to that device.

1. For CHAP, configure host name authentication and the secret or password for each remote system with which authentication is required.

2. Map the protocol address to the name of the host calling in.

To enable PPP encapsulation, use the following commands beginning in interface configuration mode:

Command

Purpose

Step 1

Enables PPP on an interface.

Step 2

]

or

Enables CHAP on an interface.

Enables PAP on an interface.

Step 3

For any host calling in to the local router or access server, maps its host name (case-sensitive) to the next hop address used to reach it.

Repeat this step for each host calling in to this interface.

Step 4

Returns to global configuration mode.

Step 5

Specifies the password to be used in CHAP caller identification. Optionally, you can specify the maximum number of connections a user can establish.

command, and PPP encapsulation and name authentication on all the interfaces the user will be accessing.

entry for each remote system from which the local router or access server requires authentication.

Specifying Physical Interfaces and Assigning Them to the Dialer Rotary Group

To assign a physical interface to a dialer rotary group, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

or

Specifies a physical interface to use and begins interface configuration mode.

Step 2

Assigns the specified physical interface to a dialer rotary group.

Repeat these two steps for each physical interface to be used by the dialer interface.

Configuring the Interface to Place and Receive Calls

You can configure an physical interface or dialer interface to both place and receive calls. For placing calls, the interface must be configured to map each next hop address to the telephone number to dial. For receiving calls from multiple sites, the interface must be configured to authenticate callers.

Figure 2 shows a configuration in which the central site is calling and receiving calls from multiple sites. In this configuration, multiple sites are calling in to a central site, and the central site might be calling one or more of the remote sites.

Figure 2 Hub-and-Spoke Configuration Using DDR

To configure a single line, multiple lines, or a dialer interface to place calls to and receive calls from multiple sites, perform the tasks in the following section:

- Defining One or More Dialing Destinations

- Defining the Traffic to Be Authenticated

If you intend to send traffic over other types of networks, see one of the following sections later in this chapter: “Configuring the Interface for Sending Traffic over a Frame Relay Network,” “Configuring the Interface for Sending Traffic over an X.25 Network,” or “Configuring the Interface for Sending Traffic over a LAPB Network.”

Defining One or More Dialing Destinations

For calling multiple sites, an interface or dialer rotary group must be configured to map each next hop protocol address to the dial string (some form of a telephone number) used to reach it.

To define each dialing destination, use one of the following commands in interface configuration mode:

Command

Purpose

]

Defines only one dialing destination (used to configure one phone number on multiple lines only).

]

Defines one of several dialing destinations for a synchronous serial interface or a dialer interface.

]

]]

Defines one of several dialing destinations for an ISDN interface (including an ISDN PRI D channel).

]

Defines one of several dialing destinations for an asynchronous interface.

If a modem dialing chat script has not been assigned to the line or a system login chat script must be specified, define both a dialing destination and the chat scripts to use.

Repeat this task as many times as needed to ensure that all dialing destinations are reachable via some next hop address and dialed number.

Defining the Traffic to Be Authenticated

Calls from the multiple sites must be authenticated. Authentication can be done through CHAP or PAP. In addition, the interface must be configured to map the protocol address of a host to the name to use for authenticating the remote host.

To enable CHAP or PAP on an interface and authenticate sites that are calling in, use the following commands in interface configuration mode:

Command

Purpose

Step 1

Configures an interface for PPP encapsulation.

Step 2

]

or

]

Enables CHAP.

Enables PAP.

Step 3

]]

Maps the protocol address to a host name.

If the dial string is not used, the interface will be able to receive calls from the host, but will not be able to place calls to the host.

Repeat this task for each site from which the router will receive calls.

Configuring Access Control for Outgoing Calls

, it will be forwarded if it is intended for a destination known to be on a specific interface and the link is active. However, such a packet will not initiate a DDR call and will not reset the idle timer.

Configuring Access Control for Bridging

When you completed preparations for bridging over DDR, you entered global access lists to specify the protocol packets to be permitted or denied, and global dialer lists to specify which access list to use and which dialer group will place the outgoing calls.

Now you must tie those global lists to an interface configured for DDR. You do this by assigning selected interfaces to a bridge group. Because packets are bridged only among interfaces that belong to the same bridge group, you need to assign this interface and others to the same bridge group.

To assign an interface to a bridge group, use the following command in interface configuration mode:

Command

Purpose

Assigns the specified interface to a bridge group.

For examples of bridging over DDR, see the “Transparent Bridging over DDR Examples” section later in this chapter.

Configuring Access Control for Routing

).

An interface can be associated only with a single dialer access group; multiple dialer access group assignments are not allowed. To specify the dialer access group to which you want to assign an access list, use the following command in interface configuration mode:

Command

Purpose

Specifies the number of the dialer access group to which the specific interface belongs.

Customizing the Interface Settings

To customize DDR in your network, perform the tasks in the following sections as needed:

- Configuring Timers on the DDR Interface (As required)

- Setting Dialer Interface Priority (As required)

- Configuring a Dialer Hold Queue (As required)

- Configuring Bandwidth on Demand (As required)

- Disabling and Reenabling DDR Fast Switching (As required)

- Configuring Dialer Redial Options (As required)

Configuring Timers on the DDR Interface

To configure DDR interface timers, perform the tasks in the following sections as needed:

- Setting Line-Idle Time (As required)

- Setting Idle Time for Busy Interfaces (As required)

- Setting Line-Down Time (As required)

- Setting Carrier-Wait Time (As required)

Setting Line-Idle Time

To specify the amount of time for which a line will stay idle before it is disconnected, use the following command in interface configuration mode:

Command

Purpose

Sets line-idle time.

Setting Idle Time for Busy Interfaces

The dialer fast idle timer is activated if there is contention for a line. Contention occurs when a line is in use, a packet for a different next hop address is received, and the busy line is required to send the competing packet.

If the line has been idle for the configured amount of time, the current call is disconnected immediately and the new call is placed. If the line has not yet been idle as long as the fast idle timeout period, the packet is dropped because the destination is unreachable. (After the packet is dropped, the fast idle timer remains active and the current call is disconnected as soon as it has been idle for as long as the fast idle timeout). If, in the meantime, another packet is sent to the currently connected destination, and it is classified as interesting, the fast-idle timer is restarted.

To specify the amount of time for which a line for which there is contention will stay idle before the line is disconnected and the competing call is placed, use the following command in interface configuration mode:

Command

Purpose

Sets idle time for high traffic lines.

This command applies to both inbound and outbound calls.

Setting Line-Down Time

To set the length of time for which the interface stays down before it is available to dial again after a line is disconnected or fails, use the following command in interface configuration mode:

Command

Purpose

Sets the interface downtime.

This command applies to both inbound and outbound calls.

Setting Carrier-Wait Time

To set the length of time for which an interface waits for the telephone service (carrier), use the following command in interface configuration mode:

Command

Purpose

Sets the length of for which time the interface waits for the carrier to come up when a call is placed.

For asynchronous interfaces, this command sets the total time to wait for a call to connect. This time is set to allow for running the chat script.

Setting Dialer Interface Priority

You can assign dialer priority to an interface. Priority indicates which interface in a dialer rotary group will get used first. To assign priority to a dialer interface, use the following command in interface configuration mode:

Command

Purpose

Specifies which dialer interfaces will be used first.

For example, you might give one interface in a dialer rotary group higher priority than another if it is attached to a faster, more reliable modem. In this way, the higher-priority interface will be used as often as possible.

is 0 through 255. Zero is the default value and lowest priority; 255 is the highest priority. This command applies to outgoing calls only.

Configuring a Dialer Hold Queue

outgoing packets to be queued and sent as soon as the modem connection is established.

can be configured with a dialer hold queue. If a hunt group leader (of a rotary dialing group) is configured with a hold queue, all members of the group will be configured with a dialer hold queue and no hold queue for an individual member can be altered.

To establish a dialer hold queue, use the following command in interface configuration mode:

Command

Purpose

Creates a dialer hold queue and specifies the number of packets to be held in it.

As many as 100 packets can be held in an outgoing dialer hold queue.

Configuring Bandwidth on Demand

You can configure a dialer rotary group to use additional bandwidth by placing additional calls to a single destination if the load for the interface exceeds a specified weighted value. Parallel communication links are established based on traffic load. The number of parallel links that can be established to one location is not limited.

To set the dialer load threshold for bandwidth on demand, use the following command in interface configuration mode:

Command

Purpose

Configures the dialer rotary group to place additional calls to a destination, as indicated by interface load.

Once multiple links are established, they are still governed by the load threshold. If the total load falls below the threshold, an idle link will be torn down.

Disabling and Reenabling DDR Fast Switching

Fast switching is enabled by default on all DDR interfaces. When fast switching is enabled or disabled on an ISDN D channel, it is enabled or disabled on all B channels. When fast switching is enabled or disabled on a dialer interface, it is enabled or disabled on all rotary group members but cannot be enabled or disabled on the serial interfaces individually.

Fast switching can be disabled and re-enabled on a protocol-by-protocol basis. To disable fast switching and re-enable it, use one of the following protocol-specific commands in interface configuration mode:

Command

Purpose

Disables IP fast switching over a DDR interface.

Disables distributed IP fast switching over a DDR interface. This feature works in Cisco 7500 routers with a Versatile Interface Processor (VIP) card.

Enables distributed IP fast switching over a DDR interface. This feature works in Cisco 7500 routers with a VIP card.

Disables IPX fast switching over a DDR interface.

Reenables IPX fast switching over a DDR interface.

Configuring Dialer Redial Options

By default, the Cisco IOS software generates a single dial attempt for each interesting packet. Dialer redial allows the dialer to be configured to make a maximum number of redial attempts if the first dial-out attempt fails, wait a specific interval between redial attempts, and disable the interface for a specified duration if all redial attempts fail. New dialout attempts will not be initiated if a redial is pending to the same destination.

To configure redial options, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Enters interface configuration mode.

Step 2

Configures redial options on the router.

Sending Traffic over Frame Relay, X.25, or LAPB Networks

An interface configured for DDR can send traffic over networks that require Link Access Procedure, Balanced (LAPB), X.25, or Frame Relay encapsulation.

Before Cisco IOS software Release 12.0(6)T, encapsulation techniques such as Frame Relay, High-Level Data Link Control (HDLC), LAPB-TA, and X.25 could support only one ISDN B-channel connection over the entire link. HDLC and PPP could support multiple B channels, but the entire ISDN link needed to use the same encapsulation. Dynamic multiple encapsulations allow incoming calls over ISDN to be assigned encapsulation type based on calling line identification (CLID) or Dialed Number Identification Service (DNIS). With dynamic multiple encapsulations, once CLID binding is completed, the topmost interface is always used for all configuration and data structures. The ISDN B channel becomes a forwarding device, and the configuration on the D channel is ignored, thereby allowing the different encapsulation types and per-user configurations.

To configure an interface for those networks, perform the tasks in the following sections:

- Configuring the Interface for Sending Traffic over a Frame Relay Network (As Required)

- Configuring the Interface for Sending Traffic over an X.25 Network (As Required)

- Configuring the Interface for Sending Traffic over a LAPB Network (As Required)

Configuring the Interface for Sending Traffic over a Frame Relay Network

Access to Frame Relay networks is now available through dialup connections and leased lines. Dialup connectivity allows Frame Relay networks to be extended to sites that do not generate enough traffic to justify leased lines, and also allows a Frame Relay network to back up another network or point-to-point line.

DDR over Frame Relay is supported for synchronous serial and ISDN interfaces and for rotary groups, and is available for in-band, DTR, and ISDN dialers.

interface can be used (dialed, connected, and active) in a rotary group or with ISDN.

Dynamic multiple encapsulations support the following Frame Relay features:

- Frame Relay RTP Header Compression (RFC 1889)

- Frame Relay TCP/IP Header Compression

- Legacy DDR over Frame Relay

- Frame Relay Interface/Subinterface Backup

Dynamic multiple encapsulations support at least four Frame Relay PVCs on either dialer interfaces or dialer subinterfaces.

Note Frame Relay encapsulations in the dynamic multiple encapsulations feature do not support IETF or Cisco Encapsulation for IBM Systems Network Architecture (SNA). Frame Relay for SNA support is not applicable.

Configuration Restrictions

The following restrictions apply to DDR used over Frame Relay:

- Frame Relay is not available for asynchronous dialers.

- The Frame Relay dynamic multiple encapsulations does not provide bidirectional support.

- With the dynamic multiple encapsulations, there is no process switching for Frame Relay packets; these packets are always fast switched.

- Like HDLC, LAPB, X.25 and Frame Relay do not provide authentication. However, ISDN dialers can offer some authentication through the caller ID feature.

- Only one ISDN B channel can be dialed at any one time. When configuring a rotary group, you can use only one serial interface.

Note Frame Relay subinterfaces work the same on dialup connections as they do on leased lines.

Configuration Overview

No new commands are required to support DDR over Frame Relay. In general, you configure Frame Relay and configure DDR. In general, to configure an interface for DDR over Frame Relay, perform the following tasks:

- Specify the interface.

- Specify the protocol identifiers for the interface.

For example, enter the IP address and mask, the IPX network number, and the AppleTalk cable range and zone.

- Configure Frame Relay, as described in the chapter “Configuring Frame Relay” in the Cisco IOS Wide-Area Networking Configuration Guide .

As a minimum, you must enable Frame Relay encapsulation and decide whether you need to do static or dynamic address mapping. If you decide to do dynamic mapping, you need not enter a command because Inverse ARP is enabled by default. If you decide to do static mapping, you must enter Frame Relay mapping commands.

You can then configure various options as needed for your Frame Relay network topology.

- Configure DDR.

At a minimum, you must decide and configure the interface for outgoing calls only, incoming calls only, or both outgoing and incoming calls.

You can also configure DDR for your routed protocols (as specified in the chapter “Preparing to Configure DDR”) and for snapshot routing (as specified in the chapter “Configuring Snapshot Routing” later in this publication). You can also customize DDR on your router or access server (as described in the “Customizing the Interface Settings” section later in this chapter).

For examples of configuring various interfaces for DDR over Frame Relay, see the section “Frame Relay Support Examples” later in this chapter.

Configuring the Interface for Sending Traffic over an X.25 Network

X.25 interfaces can now be configured to support DDR. Synchronous serial and ISDN interfaces on Cisco routers and access servers can be configured for X.25 addresses, X.25 encapsulation, and mapping of protocol addresses to the X.25 address of a remote host. In-band, DTR, and ISDN dialers can be configured to support X.25 encapsulation, but rotary groups cannot.

Remember that for ISDN interfaces, once CLID binding is completed, the topmost interface is always used for all configuration and data structures. The ISDN B channel becomes a forwarding device, and the configuration on the D channel is ignored, thereby allowing the different encapsulation types and per-user configurations. For X.25 encapsulations, the configurations reside on the dialer profile. The Dynamic Multiple Encapsulations feature provides support for packet assembler/disassembler (PAD) traffic and X.25 encapsulated and switched packets.

To configure an interface to support X.25 and DDR, use the following X.25-specific commands in interface configuration mode:

Command

Purpose

Step 1

Configures the interface to use X.25 encapsulation.

Step 2

Assigns an X.25 address to the interface.

Step 3

]

Sets up the LAN protocols-to-remote host address mapping.

The order of DDR and X.25 configuration tasks is not critical; you can configure DDR before or after X.25, and you can even mix the DDR and X.25 commands.

For an example of configuring an interface for X.25 encapsulation and then completing the DDR configuration, see the section “X.25 Support Configuration Example” later in this chapter.

Configuring the Interface for Sending Traffic over a LAPB Network

DDR over serial lines now supports LAPB encapsulation, in addition to the previously supported PPP, HDLC, and X.25 encapsulations.

LAPB encapsulation is supported on synchronous serial, ISDN, and dialer rotary group interfaces, but not on asynchronous dialers.

Because the default encapsulation is HDLC, you must explicitly configure LAPB encapsulation. To configure an interface to support LAPB encapsulation and DDR, use the following command in interface configuration mode:

Command

Purpose

]

Specifies LAPB encapsulation.

.

For an example of configuring an interface for DDR over LAPB, see the section “X.25 Support Configuration Example” later in this chapter.

Monitoring DDR Connections

To monitor DDR connections and snapshot routing, use the following commands in privileged EXEC mode:

Command

Purpose

]

Displays general diagnostics about the DDR interface.

Displays current dialer maps, next-hop protocol addresses, user names, and the interfaces on which they are configured.

Displays information about the ISDN interface.

]

Displays status about the IPX interface.

Displays information about the IPX packets sent by the router or access server, including watchdog counters.

Displays information about the AppleTalk packets sent by the router or access server.

Displays information about the Banyan VINES packets sent by the router or access server.

Displays information about the DECnet packets sent by the router or access server.

Displays information about the XNS packets sent by the router or access server.

Clears the values of the general diagnostic statistics.

Configuration Examples for Legacy DDR Hub

The following sections provide various DDR configuration examples:

- Transparent Bridging over DDR Examples

- DDR Configuration in an IP Environment Example

- AppleTalk Configuration Example

- Banyan VINES Configuration Example

- DECnet Configuration Example

- ISO CLNS Configuration Example

- XNS Configuration Example

- Hub-and-Spoke DDR for Asynchronous Interfaces and Authentication Example

- Single Site or Multiple Sites Dialing Configuration Example

- Multiple Destinations Configuration Example

- Dialer Interfaces and Dialer Rotary Groups Example

- DDR Configuration Using Dialer Interface and PPP Encapsulation Example

- Two-Way DDR with Authentication Example

- Frame Relay Support Examples

- X.25 Support Configuration Example

- LAPB Support Configuration Example

Transparent Bridging over DDR Examples

The following two examples differ only in the packets that cause calls to be placed. The first example specifies by protocol (any bridge packet is permitted to cause a call to be made); the second example allows a finer granularity by specifying the Ethernet type codes of bridge packets.

The first example configures serial interface 1 for DDR bridging. Any bridge packet is permitted to cause a call to be placed.

no ip routing

!

interface Serial1

no ip address

encapsulation ppp

dialer in-band

dialer enable-timeout 3

dialer map bridge name urk broadcast 8985

dialer hold-queue 10

dialer-group 1

ppp authentication chap

bridge-group 1

pulse-time 1

!

dialer-list 1 protocol bridge permit

bridge 1 protocol ieee

bridge 1 hello 10

command that refers to the specified access list.

no ip routing

!

interface Serial1

no ip address

encapsulation ppp

dialer in-band

dialer enable-timeout 3

dialer map bridge name urk broadcast 8985

dialer hold-queue 10

dialer-group 1

ppp authentication chap

bridge-group 1

pulse-time 1

!

access-list 200 permit 0x0800 0xFFF8

!

dialer-list 1 protocol bridge list 200

bridge 1 protocol ieee

bridge 1 hello 10

DDR Configuration in an IP Environment Example

).

interface serial 1

ip address 172.18.126.1 255.255.255.0

dialer in-band

dialer idle-timeout 600

dialer string 5551234

pulse-time 1

! The next command adds this interface to the dialer access group defined with

! the dialer-list command.

dialer-group 1

!

! The first access list statement, below, specifies that IGRP updates are not

! interesting packets. The second access-list statement specifies that all

! other IP traffic such as Ping, Telnet, or any other IP packet is interesting.

! The dialer-list command then creates dialer access group 1 and states that

! access list 101 is to be used to classify packets as interesting or

! uninteresting. The ip route commands specify that there is a route to network

! 172.18.29.0 and to network 172.18.1.0 via 172.18.126.2. This means that

! several destination networks are available through a router that is dialed

! from interface serial 1.

!

access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

dialer-list 1 list 101

ip route 172.18.29.0 172.18.126.2

ip route 172.18.1.0 172.18.126.2

ip local pool dialin 10.102.126.2 10.102.126.254

command must be used so that DTR is dropped for enough time to allow the modem to disconnect.

AppleTalk Configuration Example

The following example configures DDR for AppleTalk access using an ISDN BRI. Two access lists are defined: one for IP and Interior Gateway Routing Protocol (IGRP) and one for AppleTalk. AppleTalk packets from network 2141 only (except broadcast packets) can initiate calls.

interface BRI0

ip address 172.16.20.107 255.255.255.0

encapsulation ppp

appletalk cable-range 2141-2141 2141.65

appletalk zone SCruz-Eng

no appletalk send-rtmps

dialer map ip 172.16.20.106 broadcast 1879

dialer map appletalk 2141.66 broadcast 1879

dialer-group 1

!

access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

access-list 601 permit cable-range 2141-2141 broadcast-deny

access-list 601 deny other-access

!

dialer-list 1 list 101

dialer-list 1 list 601

Banyan VINES Configuration Example

The following example configures a router for VINES and IP DDR with in-band dialing. The VINES access list does not allow RTP routing updates to place a call, but any other data packet is interesting.

vines routing BBBBBBBB:0001

!

hostname RouterA

!

username RouterB password 7 030752180500

username RouterC password 7 00071A150754

!

interface serial 0

ip address 172.18.170.19 255.255.255.0

encapsulation ppp

vines metrics 10

vines neighbor AAAAAAAA:0001 0

dialer in-band

dialer map ip 172.18.170.151 name RouterB broadcast 4155551234

dialer map vines AAAAAAAA:0001 name RouterC broadcast 4155551212

dialer-group 1

ppp authentication chap

pulse-time 1

!

access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

!

vines access-list 107 deny RTP 00000000:0000 FFFFFFFF:FFFF 00000000:0000 FFFFFFFF:FFFF

vines access-list 107 permit IP 00000000:0000 FFFFFFFF:FFFF 00000000:0000 FFFFFFFF:FFFF

!

dialer-list 1 protocol ip list 101

dialer-list 1 protocol vines list 107

DECnet Configuration Example

The following example configures a router for DECnet DDR with in-band dialing:

decnet routing 10.19

username RouterB password 7 030752180531

!

interface serial 0

no ip address

decnet cost 10

encapsulation ppp

dialer in-band

dialer map decnet 10.151 name RouterB broadcast 4155551212

dialer-group 1

ppp authentication chap

pulse-time 1

!

access-list 301 permit 10.0 0.1023 0.0 63.1023

dialer-list 1 protocol decnet list 301

ISO CLNS Configuration Example

The following example configures a router for International Organization for Standardization Connectionless Network Service (ISO CLNS) DDR with in-band dialing:

username RouterB password 7 111C140B0E

clns net 47.0004.0001.0000.0c00.2222.00

clns routing

clns filter-set ddrline permit 47.0004.0001....

!

interface serial 0

no ip address

encapsulation ppp

dialer in-band

dialer map clns 47.0004.0001.0000.0c00.1111.00 name RouterB broadcast 1212

dialer-group 1

ppp authentication chap

clns enable

pulse-time 1

!

clns route default serial 0

dialer-list 1 protocol clns list ddrline

XNS Configuration Example

The following example configures a router for XNS DDR with in-band dialing. The access lists deny broadcast traffic to any host on any network, but allow all other traffic.

xns routing 0000.0c01.d8dd

username RouterB password 7 111B210A0F

interface serial 0

no ip address

encapsulation ppp

xns network 10

dialer in-band

dialer map xns 10.0000.0c01.d877 name RouterB broadcast 4155551212

dialer-group 1

ppp authentication chap

pulse-time 1

access-list 400 deny -1 -1.ffff.ffff.ffff 0000.0000.0000

access-list 400 permit -1 10

dialer-list 1 protocol xns list 400

Hub-and-Spoke DDR for Asynchronous Interfaces and Authentication Example

You can set up DDR to provide service to multiple remote sites. In a hub-and-spoke configuration, you can use a generic configuration script to set up each remote connection. Figure 3 illustrates a typical hub-and-spoke configuration.

Figure 3 Hub-and-Spoke DDR Configuration

The examples in the following sections show how to create this configuration.

Spoke Topology Configuration

The following commands are executed on the spoke side of the connection. (A different “spoke” password must be specified for each remote client.) The configuration provides authentication by identifying a password that must be provided on each end of the connection.

interface ethernet 0

ip address 172.30.44.1 255.255.255.0

!

interface async 7

async mode dedicated

async default ip address 172.19.45.1

ip address 172.30.45.2 255.255.255.0

encapsulation ppp

ppp authentication chap

dialer in-band

dialer map ip 172.30.45.1 name hub system-script hub 1234

dialer map ip 172.30.45.255 name hub system-script hub 1234

dialer-group 1

!

ip route 172.30.43.0 255.255.255.0 172.30.45.1

ip default-network 172.30.0.0

chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT

chat-script hub ““ ““ name: spoke1 word” <spoke1-passwd> PPP

dialer-list 1 protocol ip permit

!

username hub password <spoke1-passwd>

!

router igrp 109

network 172.30.0.0

passive-interface async 7

!

line 7

modem InOut

speed 38400

flowcontrol hardware

modem chat-script generic

Hub Router Configuration

The following commands are executed on the local side of the connection—the hub router. The commands configure the server for communication with three clients and provide authentication by identifying a unique password for each “spoke” in the hub-and-spoke configuration.

interface ethernet 0

ip address 172.30.43.1 255.255.255.0

!

interface async 7

async mode interactive

async dynamic address

dialer rotary-group 1

!

interface async 8

async mode interactive

async dynamic address

dialer rotary-group 1

!

interface dialer 1

ip address 172.30.45.2 255.255.255.0

no ip split-horizon

encapsulation ppp

ppp authentication chap

dialer in-band

dialer map ip 172.30.45.2 name spoke1 3333

dialer map ip 172.30.45.2 name spoke2 4444

dialer map ip 172.30.45.2 name spoke3 5555

dialer map ip 172.30.45.255 name spoke1 3333

dialer map ip 172.30.45.255 name spoke2 4444

dialer map ip 172.30.45.255 name spoke3 5555

dialer-group 1

!

ip route 172.30.44.0 255.255.255.0 172.30.45.2

ip route 172.30.44.0 255.255.255.0 172.30.45.3

ip route 172.30.44.0 255.255.255.0 172.30.45.4

dialer-list 1 protocol ip list 101

access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT

!

username spoke1 password <spoke1-passwd>

username spoke2 password <spoke2-passwd>

username spoke3 password <spoke3-passwd>

username spoke1 autocommand ppp 172.30.45.2

username spoke2 autocommand ppp 172.30.45.3

username spoke3 autocommand ppp 172.30.45.4

!

router igrp 109

network 172.30.0.0

redistribute static

!

line 7

login tacacs

modem InOut

speed 38400

flowcontrol hardware

modem chat-script generic

Single Site or Multiple Sites Dialing Configuration Example

The following example is based on the configuration shown in Figure 4; the router receives a packet with a next hop address of 10.1.1.1.

Figure 4 Sample Dialer String or Dialer Map Configuration

command is used to specify the string (telephone number) to be called.

interface serial 1

dialer in-band

dialer string 5555555

command is used to map next hop addresses to phone numbers.

interface serial 1

dialer in-band

dialer map ip 10.1.1.1 5555555

dialer map ip 10.2.2.2 6666666

Multiple Destinations Configuration Example

The following example shows how to specify multiple destination numbers to dial for outgoing calls:

interface serial 1

ip address 172.18.126.1 255.255.255.0

dialer in-band

dialer wait-for-carrier-time 100

pulse-time 1

dialer-group 1

dialer map ip 172.18.126.10 5558899

dialer map ip 172.18.126.15 5555555

!

access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

dialer-list 1 protocol ip list 101

As in the “DDR Configuration in an IP Environment Example” section, a pulse time is assigned and a dialer access group specified.

value of 172.18.126.15 is detected.

Dialer Interfaces and Dialer Rotary Groups Example

command:

! PPP encapsulation is enabled for interface dialer 1.

interface dialer 1

encapsulation ppp

dialer in-band

ip address 172.18.2.1 255.255.255.0

ip address 172.18.2.1 255.255.255.0 secondary

! The first dialer map command allows remote site YYY and the central site to

! call each other. The second dialer map command, with no dialer string, allows

! remote site ZZZ to call the central site but the central site cannot call

! remote site ZZZ (no phone number).

!

dialer map ip 172.18.2.5 name YYY 1415553434

dialer map ip 172.18.2.55 name ZZZ

!

! The DTR pulse signals for three seconds on the interfaces in dialer group 1.

! This holds the DTR low so the modem can recognize that DTR has been dropped.

pulse-time 3

! Serial interfaces 1 and 2 are placed in dialer rotary group 1. All the

! interface configuration commands (the encapsulation and dialer map commands

! shown earlier in this example) that applied to interface dialer 1 also apply

! to these interfaces.

interface serial 1

dialer rotary-group 1

interface serial 2

dialer rotary-group 1

DDR Configuration Using Dialer Interface and PPP Encapsulation Example

The following example shows a configuration for XXX, the local router shown in Figure 5. In this example, remote Routers YYY and ZZZ can call Router XXX. Router XXX has dialing information only for Router YYY and cannot call Router ZZZ.

Figure 5 DDR Configuration

Router XXX Configuration

username YYY password theirsystem

username ZZZ password thatsystem

4

! Create a dialer interface with PPP encapsulation and CHAP authentication.

interface dialer 1

ip address 172.18.2.1 255.255.255.0

ip address 172.24.4.1 255.255.255.0 secondary

encapsulation ppp

ppp authentication chap

dialer in-band

dialer group 1

! The first dialer map command indicates that calls between the remote site

! YYY and the central site will be placed at either end. The second dialer

! map command, with no dialer string, indicates that remote site ZZZ will call

! the central site but the central site will not call out.

dialer map ip 172.18.2.5 name YYY 1415553434

dialer map ip 172.24.4.5 name ZZZ

! The DTR pulse holds the DTR low for three seconds, so the modem can recognize

! that DTR has been dropped.

pulse-time 3

!

! Place asynchronous serial interfaces 1 and 2 in dialer group 1. The interface commands

! applied to dialer group 1 (for example, PPP encapsulation and CHAP) apply to these

! interfaces.

!

interface async 1

dialer rotary-group 1

interface async 2

dialer rotary-group 1

Two-Way DDR with Authentication Example

You can set up two-way DDR with authentication in which both the client and server have dial-in access to each other. This configuration is demonstrated in the following two subsections.

Remote Configuration

The following commands are executed on the remote side of the connection. This configuration provides authentication by identifying a password that must be provided on each end of the connection.

username local password secret1

username remote password secret2

!

interface ethernet 0

ip address 172.30.44.1 255.255.255.0

!

interface async 7

ip address 172.30.45.2 255.255.255.0

async mode dedicated

async default ip address 172.30.45.1

encapsulation ppp

dialer in-band

dialer string 1234

dialer-group 1

!

ip route 172.30.43.0 255.255.255.0 async 7

ip default-network 172.30.0.0

chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT

dialer-list 1 protocol ip permit

!

line 7

no exec

modem InOut

speed 38400

flowcontrol hardware

modem chat-script generic

Local Configuration

The following commands are executed on the local side of the connection. As with the remote side configuration, this configuration provides authentication by identifying a password for each end of the connection.

username remote password secret1

username local password secret2

!

interface ethernet 0

ip address 172.30.43.1 255.255.255.0

!

interface async 7

async mode dedicated

async default ip address 172.30.45.2

dialer rotary-group 1

!

interface async 8

async mode dedicated

async default ip address 172.30.45.2

dialer rotary-group 1

!

interface dialer 1

ip address 172.30.45.2 255.255.255.0

encapsulation ppp

ppp authentication chap

dialer in-band

dialer map ip 172.30.45.2 name remote 4321

dialer load-threshold 80

!

ip route 172.30.44.0 255.255.255.0 172.30.45.2

chat-script generic ABORT BUSY ABORT NO ## AT OK ATDT\T TIMEOUT 30 CONNECT

!

router igrp 109

network 172.30.0.0

redistribute static

passive-interface async 7

!

line 7

modem InOut

speed 38400

flowcontrol hardware

modem chat-script generic

Frame Relay Support Examples

The examples in this section present various combinations of interfaces, Frame Relay features, and DDR features.

Frame Relay Access with In-Band Dialing and Static Mapping

The following example configures a router for IP over Frame Relay using in-band dialing. A Frame Relay static map is used to associate the next hop protocol address to the DLCI. The dialer string allows dialing to only one destination.

interface Serial0

ip address 10.1.1.1 255.255.255.0

encapsulation frame-relay

frame-relay map ip 10.1.1.2 100 broadcast

dialer in-band

dialer string 4155551212

dialer-group 1

!

access-list 101 deny igrp any host 255.255.255.255

access-list 101 permit ip any any

!

dialer-list 1 protocol ip list 101

Frame Relay Access with ISDN Dialing and DDR Dynamic Maps

The following example shows a BRI interface configured for Frame Relay and for IP, Internet Protocol Exchange (IPX), and AppleTalk routing. No static maps are defined because this setup relies on Frame Relay Local Management Interface (LMI) signaling and Inverse ARP to determine the network addresses-to-DLCI mappings dynamically. (Because Frame Relay Inverse ARP is enabled by default, no command is required.)

interface BRI0

ip address 10.1.1.1 255.255.255.0

ipx network 100

appletalk cable-range 100-100 100.1

appletalk zone ISDN

no appletalk send-rtmps

encapsulation frame-relay IETF

dialer map ip 10.1.1.2 broadcast 4155551212

dialer map apple 100.2 broadcast 4155551212

dialer map ipx 100.0000.0c05.33ed broadcast 4085551234

dialer-group 1

!

access-list 101 deny igrp any host 255.255.255.255

access-list 101 permit ip any any

access-list 901 deny -1 FFFFFFFF 452

access-list 901 deny -1 FFFFFFFF 453

access-list 901 deny -1 FFFFFFFF 457

access-list 901 deny -1 FFFFFFFF 0 FFFFFFFF 452

access-list 901 deny -1 FFFFFFFF 0 FFFFFFFF 453

access-list 901 deny -1 FFFFFFFF 0 FFFFFFFF 457

access-list 901 permit -1

access-list 601 permit cable-range 100-100 broadcast-deny

access-list 601 deny other-access

!

dialer-list 1 protocol ip list 101

dialer-list 1 protocol novell list 901

dialer-list 1 protocol apple list 601

Frame Relay Access with ISDN Dialing and Subinterfaces

The following example shows a BRI interface configured for Frame Relay and for IP, IPX, and AppleTalk routing. Two logical subnets are used; a point-to-point subinterface and a multipoint subinterface are configured. Frame Relay Annex A (LMI type Q933a) and Inverse ARP are used for dynamic routing.

interface BRI0

no ip address

encapsulation frame-relay

dialer string 4155551212

dialer-group 1

frame-relay lmi-type q933a

!

interface BRI0.1 multipoint

ip address 10.1.100.1 255.255.255.0

ipx network 100

appletalk cable-range 100-100 100.1

appletalk zone ISDN

no appletalk send-rtmps

frame-relay interface-dlci 100

frame-relay interface-dlci 110

frame-relay interface-dlci 120

!

interface BRI0.2 point-to-point

ip address 10.1.200.1 255.255.255.0

ipx network 200

appletalk cable-range 200-200 200.1

appletalk zone ISDN

no appletalk send-rtmps

frame-relay interface-dlci 200 broadcast IETF

!

access-list 101 deny igrp any host 255.255.255.255

access-list 101 permit ip any any

access-list 901 deny -1 FFFFFFFF 452

access-list 901 deny -1 FFFFFFFF 453

access-list 901 deny -1 FFFFFFFF 457

access-list 901 deny -1 FFFFFFFF 0 FFFFFFFF 452

access-list 901 deny -1 FFFFFFFF 0 FFFFFFFF 453

access-list 901 deny -1 FFFFFFFF 0 FFFFFFFF 457

access-list 901 permit -1

access-list 601 permit cable-range 100-100 broadcast-deny

access-list 601 permit cable-range 200-200 broadcast-deny

access-list 601 deny other-access

dialer-list 1 protocol ip list 101

dialer-list 1 protocol novell list 901

dialer-list 1 protocol apple list 601

X.25 Support Configuration Example

The following example configures a router to support X.25 and DTR dialing:

interface serial 0

ip address 172.18.170.19 255.255.255.0

encapsulation x25

x25 address 12345

x25 map ip 172.18.171.20 67890 broadcast

dialer dtr

dialer-group 1

!

access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

!

dialer-list 1 protocol ip list 101

LAPB Support Configuration Example

The following example configures a router for LAPB encapsulation and in-band dialing:

interface serial 0

ip address 172.18.170.19 255.255.255.0

encapsulation lapb

dialer in-band

dialer string 4155551212

dialer-group 1

!

access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

!

dialer-list 1 protocol ip list 101

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001-2009 Cisco Systems, Inc. All rights reserved.

Configuring Peer-to-Peer DDR with Dialer Profiles

This chapter describes how to configure the Cisco IOS software for the Dialer Profiles feature implementation of dial-on-demand routing (DDR). It includes the following main sections:

- Dialer Profiles Overview

- How to Configure Dialer Profiles

- Monitoring and Maintaining Dialer Profile Connections

- Configuration Examples Dialer Profiles

For information about preparations for configuring dialer profiles, see the chapter “Preparing to Configure DDR” in this publication.

The Dialer Profiles feature is contrasted with legacy DDR. For information about legacy DDR, see the other chapters in the “Dial-on-Demand Routing” part of this publication.

For information about dial backup using dialer profiles, see the chapter “Configuring Dial Backup with Dialer Profiles” in this publication.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

Dialer Profiles Overview

Dialer profiles allow the configuration of physical interfaces to be separated from the logical configuration required for a call, and they also allow the logical and physical configurations to be bound together dynamically on a per-call basis.

consists of the following elements:

- A dialer interface (a logical entity) configuration including one or more dial strings (each of which is used to reach one destination subnetwork)

- A dialer map class that defines all the characteristics for any call to the specified dial string

- An ordered dialer pool of physical interfaces to be used by the dialer interface

Note Dialer profiles support most routed protocols; however, International Organization for Standardization Connectionless Network Service (ISO CLNS) is not supported.

New Dialer Profile Model

In earlier releases of the Cisco IOS software, dialer profiles in the same dialer pool needed encapsulation-specific configuration information entered under both the dialer profile interface and the ISDN interface. If any conflict arose between the logical and the physical interfaces, the dialer profile failed to work.

In the new dialer profile model introduced by the Dynamic Multiple Encapsulations feature in Cisco IOS Release 12.1, the configuration on the ISDN interface is ignored and only the configuration on the profile interface is used, unless PPP name binding is used. Before a successful bind by CLID occurs, no encapsulation type and configuration are assumed or taken from the physical interfaces.

When PPP is used and a caller identification (CLID) bind fails, a dialer profile still can be matched by PPP name authentication. In the new dialer profile model, multiple attempts are made to find a matching profile.

The dialer profile software binds an incoming call on a physical dialer interface according to the following events, and in the order listed:

commands configured on that profile.

command on a dialer profile using a pool of which the physical interface is a member.

command on a dialer profile using a pool of which the physical interface is a member.

command configuration on a dialer profile using a pool of which the physical interface is a member, then the dialer profile software binds to that dialer profile.

command on the dialer profile that was bound to the call.

PPP encapsulation on an ISDN link is different from other encapsulation types because it runs on the B channel rather than the dialer profile interface. There are two possible configuration sources in a profile bind: the D and the dialer profile interfaces. Hence, a configuration conflict between the sources is possible. If a successful bind is accomplished by name authentication, the configuration used to bring PPP up is the one on the D interface. This is the name used to locate a dialer profile for the bind. The configuration on an ISDN interface goes under the D rather than a B channel, although B channels inherit the configuration from their D interface.

multilink command is configured on the D interface, but not on the dialer profile interface. The actual per-user configuration is the one on the dialer profile interface. In this case, per-user configuration is not achieved unless link control protocol (LCP) and authentication are renegotiated. Because PPP client software often does not accept renegotiation, this workaround is not acceptable. Therefore, the D interface configuration takes precedence over the dialer profile interface configuration. This is the only case where the configuration of the dialer profile is overruled.

Dialer Interface

A dialer interface configuration includes all settings needed to reach a specific destination subnetwork (and any networks reached through it). Multiple dial strings can be specified for the same dialer interface, each dial string being associated with a different dialer map class.

Dialer Map Class

The dialer map class defines all the characteristics for any call to the specified dial string. For example, the map class for one destination might specify a 56-kbps ISDN speed; the map class for a different destination might specify a 64-kbps ISDN speed.

Dialer Pool

Each dialer interface uses a dialer pool, a pool of physical interfaces ordered on the basis of the priority assigned to each physical interface. A physical interface can belong to multiple dialer pools, contention being resolved by priority. ISDN BRI and PRI interfaces can set a limit on the minimum and maximum number of B channels reserved by any dialer pools. A channel reserved by a dialer pool remains idle until traffic is directed to the pool.

When dialer profiles are used to configure DDR, a physical interface has no configuration settings except encapsulation and the dialer pools with which the interface belongs.

Note The preceding paragraph has one exception: commands that apply before authentication is complete must be configured on the physical (or BRI or PRI) interface and not on the dialer profile. Dialer profiles do not copy PPP authentication commands (or LCP commands) to the physical interface.

Figure 1 shows a typical application of dialer profiles. Router A has dialer interface 1 for DDR with subnetwork 10.1.1.0, and dialer interface 2 for DDR with subnetwork 10.2.2.0. The IP address for dialer interface 1 is its address as a node in network 10.1.1.0; at the same time, that IP address serves as the IP address of the physical interfaces used by the dialer interface 1. Similarly, the IP address for dialer interface 2 is its address as a node in network 10.2.2.0.

Figure 1 Typical Dialer Profiles Application

A dialer interface uses only one dialer pool. A physical interface, however, can be a member of one or many dialer pools, and a dialer pool can have several physical interfaces as members.

Figure 2 illustrates the relations among the concepts of dialer interface, dialer pool, and physical interfaces. Dialer interface 0 uses dialer pool 2. Physical interface BRI 1 belongs to dialer pool 2 and has a specific priority in the pool. Physical interface BRI 2 also belongs to dialer pool 2. Because contention is resolved on the basis of priority levels of the physical interfaces in the pool, BRI 1 and BRI 2 must be assigned different priorities in the pool. Perhaps BRI 1 is assigned priority 50 and BRI 2 is assigned priority 100 in dialer pool 2 (a priority of 100 is higher than a priority of 50). BRI 2 has a higher priority in the pool, and its calls will be placed first.

Figure 2 Relations Among Dialer Interfaces, Dialer Pools, and Physical Interfaces

How to Configure Dialer Profiles

To configure dialer profiles, perform the task in the following section:

- Configuring a Dialer Profile (Required)

The following tasks can be configured whether you use legacy DDR or dialer profiles. Perform these tasks as needed for your network:

- Configuring Dialer Profiles for Routed Protocols (As required)

- Configuring Dialer Profiles for Transparent Bridging (As required)

See the “Verifying the Dynamic Multiple Encapsulations Feature” section later in this chapter for tips on verifying that the feature is running in your network. See the “Configuration Examples Dialer Profiles” section at the end of this chapter for comprehensive configuration examples.

Configuring a Dialer Profile

To configure a dialer profile, perform the tasks in the following sections as required:

- Configuring a Dialer Interface (Required)

- Fancy Queueing and Traffic Shaping on Dialer Profile Interfaces (Optional)

- Configuring a Map Class (Optional)

- Configuring the Physical Interfaces (Required)

Configuring a Dialer Interface

Any number of dialer interfaces can be created for a router. Each dialer interface is the complete configuration for a destination subnetwork and any networks reached through it. The router on the destination subnetwork sends traffic on to the appropriate shadowed networks.

To configure a dialer interface, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Creates a dialer interface and begins interface configuration mode.

Step 2

Specifies the IP address and mask of the dialer interface as a node in the destination network to be called.

Step 3

Specifies the encapsulation type.

Step 4

Specifies the remote destination to call and the map class that defines characteristics for calls to this destination.

Step 5

Specifies the dialing pool to use for calls to this destination.

Step 6

Assigns the dialer interface to a dialer group.

Step 7

Specifies an access list by list number or by protocol and list number to define the “interesting” packets that can trigger a call.

Fancy Queueing and Traffic Shaping on Dialer Profile Interfaces

In earlier releases of the Cisco IOS software, fancy queueing and traffic shaping were configured under the physical interfaces, therefore the same queueing or traffic shaping scheme needed to be applied to all users that were sharing the same ISDN link.

Beginning in Cisco IOS Release 12.1, you need only configure the queueing and traffic shaping schemes you desire on the dialer profile interface and the interface will take precedence over those configured on the ISDN B-channel interface. All the per-user encapsulation configuration has been moved to the dialer profile interfaces, separating it from hardware interfaces to make it dynamic and also to make per-user queueing and traffic shaping configuration possible.

Note Per-user fancy queueing and traffic shaping work with both process switching and fast switching in the new dialer profile model. However, Frame Relay Traffic Shaping (FRTS) is not supported on the new dialer profile model.

for more information about FRTS.

Configuring a Map Class

Map-class configuration is optional but allows you to specify different characteristics for different types of calls on a per-call-destination basis. For example, you can specify higher priority and a lower wait-for-carrier time for an ISDN-calls map class than for a modem-calls map class. You can also specify a different speed for some ISDN calls than for other ISDN calls.

keyword.

To specify a map class and define its characteristics, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Specifies a map class and begins map-class configuration mode.

Step 2

Specifies the fast idle timer value.

Step 3

]

Specifies the duration of idle time in seconds after which a line will be disconnected.

keyword causes only inbound traffic to reset the timer.

Step 4

Specifies the length of time to wait for a carrier when dialing out to the dial string associated with the map class.

Step 5

]

For ISDN only, specifies the bit rate used on the B channel associated with a specified map class or specifies that an ISDN semipermanent connection is to be used for calls associated with this map.

Note The dialer idle-timeout interface configuration command specifies the duration of time before an idle connection is disconnected. Previously, both inbound and outbound traffic would reset the dialer idle timer; now you can specify that only inbound traffic will reset the dialer idle timer.

Configuring the Physical Interfaces

To configure a physical interface, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Specifies the physical interface and begins interface configuration mode.

Step 2

Enables PPP encapsulation.

Step 3

Specifies PPP Challenge Handshake Authentication Protocol (CHAP) authentication, if you also want to receive calls on this interface.

Step 4

]

For ISDN interfaces, you may also specify the minimum number of channels reserved and maximum number of channels used on this interface.

value applies to both incoming and outgoing calls and sets the total number of connections for a particular dialer pool member.

Step 5

]

or

]

(Optional) Repeat Step 4 if you want to put the interface in additional dialing pools.

Repeat this procedure for additional physical interfaces that you want to use with dialer profiles.

Configuring Dialer Profiles for Routed Protocols

Both legacy DDR and dialer profiles support the following routed protocols: AppleTalk, Banyan VINES, DECnet, IP, Novell Internet Protocol Exchange (IPX), and Xerox Network System (XNS). To configure dialer profiles for a routed protocol, perform the tasks in the relevant section:

- Configuring Dialer Profiles for AppleTalk (As required)

- Configuring Dialer Profiles for Banyan VINES (As required)

- Configuring Dialer Profiles for DECnet (As required)

- Configuring Dialer Profiles for IP (As required)

- Configuring Dialer Profiles for Novell IPX (As required)

- Configuring XNS over DDR (As required)

Configuring Dialer Profiles for AppleTalk

keyword. See the section “Configuring a Dialer Interface” earlier in this chapter for more information about defining dialer lists.

Configuring Dialer Profiles for Banyan VINES

To configure DDR for Banyan VINES, use one of the following commands in global configuration mode:

Command

Purpose

or

]

Specifies a VINES standard access list.

Specifies a VINES extended access list.

keyword. See the section “Configuring a Dialer Interface” earlier in this chapter for more information about defining dialer lists.

Note The Banyan VINES neighbor command is not supported for Link Access Procedure, Balanced (LAPB) and X.25 encapsulations.

Configuring Dialer Profiles for DECnet

To configure dial-on-demand routing (DDR) for DECnet, use one of the following commands in global configuration mode:

Command

Purpose

or

]

Specifies a DECnet standard access list.

Specifies a DECnet extended access list.

keyword. See the section “Configuring a Dialer Interface” earlier in this chapter for more information about defining dialer lists.

.

Configuring Dialer Profiles for IP

To configure DDR for IP, use one of the following commands in global configuration mode:

Command

Purpose

]

or

]

Specifies an IP standard access list.

Specifies an IP extended access list.

for more information.

Configuring Dialer Profiles for Novell IPX

On DDR links for Novell IPX, the link may come up often even when all client sessions are idle because the server sends watchdog or keepalive packets to all the clients approximately every 5 minutes. You can configure a local router or access server to idle out the DDR link and respond to the watchdog packets on behalf of the clients.

To modify the dialer profiles dialer interface configuration for Novell IPX, use the following commands in interface configuration mode:

Command

Purpose

Step 1

Disables fast switching for IPX.

Step 2

or

Enables IPX watchdog spoofing.

Enables Sequenced Packet Exchange (SPX) keepalive spoofing.

Step 3

Sets the idle time after which SPX keepalive spoofing begins.

Configuring XNS over DDR

To configure XNS for DDR, use one of the following commands in global configuration mode:

Command

Purpose

Router(config)# access-list access-list-number { deny | permit } source-network [ . source-address [ source-address-mask ]] [ destination-network [ . destination-address [ destination-address-mask ]]]

or

]]]

Specifies a standard XNS access list.

Specifies an extended XNS access list.

keyword. See the section “Configuring a Dialer Interface” earlier in this chapter for more information about defining dialer lists.

Configuring Dialer Profiles for Transparent Bridging

The Cisco IOS software supports transparent bridging over both legacy DDR and dialer profiles, and it provides you some flexibility in controlling access and configuring the interface.

To configure dialer profiles for bridging, perform the tasks in the following sections:

- Defining the Protocols to Bridge (Required)

- Specifying the Bridging Protocol (Required)

- Controlling Access for Bridging (Required)

- Configuring an Interface for Bridging (Required)

Defining the Protocols to Bridge

IP packets are routed by default unless they are explicitly bridged; all others are bridged by default unless they are explicitly routed. To bridge IP packets, use the following command in global configuration mode:

Command

Purpose

Disables IP routing.

.

Specifying the Bridging Protocol

You must specify the type of spanning-tree bridging protocol to use and also identify a bridge group. To specify the spanning-tree protocol and a bridge group number, use the following command in global configuration mode:

Command

Purpose

}

Defines the type of spanning-tree protocol and identifies a bridge group.

number is used when you configure the interface and assign it to a bridge group. Packets are bridged only among members of the same bridge group.

Controlling Access for Bridging

of the following tasks:

- Permitting All Bridge Packets

- Controlling Bridging Access by Ethernet Type Codes

Note Spanning-tree bridge protocol data units (BPDUs) are always treated as uninteresting.

Permitting All Bridge Packets

To identify all transparent bridge packets as interesting, use the following command in global configuration mode:

Command

Purpose

Defines a dialer list that treats all transparent bridge packets as interesting.

Controlling Bridging Access by Ethernet Type Codes

To control access by Ethernet type codes, use the following commands in global configuration mode:

Command

Purpose

Step 1

]

Identifies interesting packets by Ethernet type codes (access list numbers must be in the range 200 to 299).

Step 2

Defines a dialer list for the specified access list.

.

Configuring an Interface for Bridging

You can perform serial interfaces or ISDN interfaces for DDR bridging. To configure an interface for DDR bridging, complete all the tasks in the following sections:

- Specifying the Interface (Required)

- Configuring the Destination (Required)

- Assigning the Interface to a Bridge Group (Required)

Specifying the Interface

To specify the interface and enter interface configuration mode, use the following command in global configuration mode:

Command

Purpose

Specifies the serial or ISDN interface and enters interface configuration mode.

Configuring the Destination

You can configure the destination by specifying either of the following:

- A dial string—for unauthenticated calls to a single site

- A dialer bridge map—when you want to use authentication

To configure the destination for bridging over a specified interface, use the following command in interface configuration mode:

Command

Purpose

Configures the dial string to call.

Note You can define only one dialer bridge map for the interface. If you enter a different bridge map, the previous one is replaced immediately.

Assigning the Interface to a Bridge Group

Packets are bridged only among interfaces that belong to the same bridge group. To assign an interface to a bridge group, use the following command in interface configuration mode:

Command

Purpose

Assigns the specified interface to a bridge group.

Monitoring and Maintaining Dialer Profile Connections

To monitor DDR dialer profile connections, use any of the following commands in privileged EXEC mode:

Command

Purpose

Displays information for the interfaces configured for DDR dialer profiles.

Displays statistics for configured interfaces. The output varies, depending on the network for which an interface has been configured.

]

Displays status about the IPX interface.

Displays information about the IPX packets sent by the router or access server, including watchdog counters.

Displays information about the AppleTalk packets sent by the router or access server.

Displays information about the Banyan VINES packets sent by the router or access server.

Displays information about the DECnet packets sent by the router or access server.

Displays information about the XNS packets sent by the router or access server.

Clears the values of the general diagnostic statistics.

Configuration Examples Dialer Profiles

The following sections provide three comprehensive configuration examples:

- Dialer Profile with Inbound Traffic Filter Example

- Dialer Profile for Central Site with Multiple Remote Sites Example

- Dialer Profile for ISDN BRI Backing Up Two Leased Lines Example

- Dynamic Multiple Encapsulations over ISDN Example

Dialer Profile with Inbound Traffic Filter Example

keyword. This command allows only inbound traffic that conforms to the dialer list to establish a connection and reset the dialer idle timer.

interface Serial0:23

no ip address

no ip directed-broadcast

encapsulation ppp

dialer pool-member 1 max-link 2

isdn switch-type primary-5ess

no cdp enable

ppp authentication chap

!

interface Dialer0

ip address 10.1.1.2 255.255.255.0

no ip directed-broadcast

encapsulation ppp

dialer remote-name 2610-2

dialer idle-timeout 30 inbound

dialer string 2481301

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication chap

ppp multilink

!

access-list 101 permit icmp any any

access-list 101 deny ip any any

dialer-list 1 protocol ip list 101

Dialer Profile for Central Site with Multiple Remote Sites Example

The following example shows a central site that can place or receive calls from three remote sites over four ISDN BRI lines. Each remote site is on a different IP subnet and has different bandwidth requirements; therefore, three dialer interfaces and three dialer pools are defined.

! This is a dialer profile for reaching remote subnetwork 10.1.1.1.

interface Dialer1

ip address 10.1.1.1 255.255.255.0

encapsulation ppp

dialer remote-name Smalluser

dialer string 4540

dialer pool 3

dialer-group 1

! This is a dialer profile for reaching remote subnetwork 10.2.2.2.

interface Dialer2

ip address 10.2.2.2 255.255.255.0

encapsulation ppp

dialer remote-name Mediumuser

dialer string 5264540 class Eng

dialer load-threshold 50 either

dialer pool 1

dialer-group 2

! This is a dialer profile for reaching remote subnetwork 10.3.3.3.

interface Dialer3

ip address 10.3.3.3 255.255.255.0

encapsulation ppp

dialer remote-name Poweruser

dialer string 4156884540 class Eng

dialer hold-queue 10

dialer load-threshold 80

dialer pool 2

dialer-group 2

! This map class ensures that these calls use an ISDN speed of 56 kbps.

map-class dialer Eng

isdn speed 56

interface BRI0

encapsulation PPP

! BRI 0 has a higher priority than BRI 1 in dialer pool 1.

dialer pool-member 1 priority 100

ppp authentication chap

interface BRI1

encapsulation ppp

dialer pool-member 1 priority 50

dialer pool-member 2 priority 50

! BRI 1 has a reserved channel in dialer pool 3; the channel remains inactive

! until BRI 1 uses it to place calls.

dialer pool-member 3 min-link 1

ppp authentication chap

interface BRI2

encapsulation ppp

! BRI 2 has a higher priority than BRI 1 in dialer pool 2.

dialer pool-member 2 priority 100

ppp authentication chap

interface BRI3

encapsulation ppp

! BRI 3 has the highest priority in dialer pool 2.

dialer pool-member 2 priority 150

ppp authentication chap

Dialer Profile for ISDN BRI Backing Up Two Leased Lines Example

The following example shows the configuration of a site that backs up two leased lines using one BRI. Two dialer interfaces are defined. Each serial (leased line) interface is configured to use one of the dialer interfaces as a backup. Both of the dialer interfaces use BRI 0, and BRI 0 is a member of the two dialer pools. Thus, BRI 0 can back up two different serial interfaces and can make calls to two different sites.

interface dialer0

ip unnumbered loopback0

encapsulation ppp

dialer remote-name Remote0

dialer pool 1

dialer string 5551212

dialer-group 1

interface dialer1

ip unnumbered loopback0

encapsulation ppp

dialer remote-name Remote1

dialer pool 2

dialer string 5551234

dialer-group 1

interface bri 0

encapsulation PPP

dialer pool-member 1

dialer pool-member 2

ppp authentication chap

interface serial 0

ip unnumbered loopback0

backup interface dialer0

backup delay 5 10

interface serial 1

ip unnumbered loopback0

backup interface dialer1

backup delay 5 10

Dynamic Multiple Encapsulations over ISDN Example

The following example shows a network access server named NAS1 with dialer profiles and LAPB, X.25, and PPP encapsulations configured. Although the BRI0 D interface uses X.25 encapsulation, the actual encapsulations running over the ISDN B channels are determined by the encapsulations configured on the profile interfaces bound to them.

D interface has no effect. Because the ppp authentication chap command is configured, even though the binding is done by CLID, PPP authentication is still performed over the name RU2 before the protocol is allowed to proceed.

command, as in the previous dialer profile model.

When there is an ISDN B-channel connection to remote user RU1 using CLID 60036, LAPB encapsulation will run on this connection once CLID binding to Dialer0 takes place. This connection will operate as a standalone link independent of other activities over other ISDN B channels.

version xx.x

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

service udp-small-servers

service tcp-small-servers

!

virtual-profile virtual-template 1

virtual-profile aaa

!

hostname NAS1

!

aaa new-model

aaa authentication ppp default radius

aaa authorization network radius

enable secret 5 $1$0Ced$YYJJl2p8f94lc/.JSgw8n1

enable password 7 153D19270D2E

!

username RU1 password 7 11260B2E1E16

username RU2 password 7 09635C221001

no ip domain-lookup

ip domain-name cisco.com

ip name-server 192.168.30.32

ip name-server 172.16.2.132

isdn switch-type basic-5ess

!

interface Virtual-Template 1

encapsulation ppp

ppp authentication chap

!

interface Ethernet0

ip address 172.21.17.11 255.255.255.0

no ip mroute-cache

no cdp enable

!

interface Serial0

ip address 10.2.2.1 255.0.0.0

shutdown

clockrate 56000

ppp authentication chap

!

interface Serial1

ip address 10.0.0.1 255.0.0.0

shutdown

!

interface BRI0

description PBX 60035

no ip address

encapsulation x25

no ip mroute-cache

no keepalive

dialer pool-member 1

dialer pool-member 2

!

interface Dialer0

ip address 10.1.1.1 255.0.0.0

encapsulation lapb dce multi

no ip route-cache

no ip mroute-cache

no keepalive

dialer remote-name RU1

dialer idle-timeout 300

dialer string 60036

dialer caller 60036

dialer pool 1

dialer-group 1

no fair-queue

!

interface Dialer1

ip address 10.1.1.1 255.0.0.0

encapsulation ppp

no ip route-cache

no ip mroute-cache

dialer remote-name RU2

dialer string 60043

dialer caller 60043

dialer pool 2

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap

!

interface Dialer2

ip address 10.1.1.1 255.0.0.0

encapsulation hdlc

dialer called 60045:12345

dialer pool 1

dialer-group 1

fair-queue

!

radius-server host 172.19.61.87

radius-server key foobar

snmp-server community public RO

!

line con 0

exec-timeout 0 0

line aux 0

transport input all

line vty 0 4

password 7 10611B320C13

login

!

end

Verifying the Dynamic Multiple Encapsulations Feature

EXEC command. Look for the reports “Bound to:” and “Interface is bound to...” while remembering that this feature applies only to ISDN.

Router# show interfaces dialer0

Dialer0 is up, line protocol is up

Hardware is Unknown

Internet address is 10.1.1.2/8

MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255

Encapsulation PPP, loopback not set

DTR is pulsed for 1 seconds on reset

Interface is bound to BRI0:1

Last input 00:00:38, output never, output hang never

Last clearing of “show interface” counters 00:05:36

Queueing strategy: fifo

Output queue 0/40, 0 drops; input queue 0/75, 0 drops

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

38 packets input, 4659 bytes

34 packets output, 9952 bytes

Bound to:

BRI0:1 is up, line protocol is up

Hardware is BRI

MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255

Encapsulation PPP, loopback not set, keepalive not set

Interface is bound to Dialer0 (Encapsulation PPP)

LCP Open, multilink Open

Last input 00:00:39, output 00:00:11, output hang never

Last clearing of “show interface” counters never

Queueing strategy: fifo

Output queue 0/40, 0 drops; input queue 0/75, 0 drops

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

78 packets input, 9317 bytes, 0 no buffer

Received 65 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

93 packets output, 9864 bytes, 0 underruns

0 output errors, 0 collisions, 7 interface resets

0 output buffer failures, 0 output buffers swapped out

4 carrier transitions

At the end of the Dialer0 display, the show interfaces command is executed on each physical interface bound to it.

In the next example, the physical interface is the B1 channel of the BRI0 link. This example also illustrates that the output under the B channel keeps all hardware counts that are not displayed under any logical or virtual access interface. The line in the report that states “Interface is bound to Dialer0 (Encapsulation LAPB)” indicates that this B interface is bound to the dialer 0 interface and that the encapsulation running over this connection is LAPB, not PPP, which is the encapsulation configured on the D interface and inherited by the B channel.

Router# show interfaces bri0:1

BRI0:1 is up, line protocol is up

Hardware is BRI

MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255

Encapsulation PPP, loopback not set, keepalive not set

Interface is bound to Dialer0 (Encapsulation LAPB)

LCP Open, multilink Open

Last input 00:00:31, output 00:00:03, output hang never

Last clearing of “show interface” counters never

Queueing strategy: fifo

Output queue 0/40, 0 drops; input queue 0/75, 0 drops

5 minute input rate 0 bits/sec, 1 packets/sec

5 minute output rate 0 bits/sec, 1 packets/sec

110 packets input, 13994 bytes, 0 no buffer

Received 91 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

135 packets output, 14175 bytes, 0 underruns

0 output errors, 0 collisions, 12 interface resets

0 output buffer failures, 0 output buffers swapped out

8 carrier transitions

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

© 2007-2009 Cisco Systems, Inc. All rights reserved.

Dialer Map VRF-Aware for an MPLS VPN

Feature History

Release

Modification

12.2(8)T

This feature was introduced.

Release 12.2(8)T and includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Prerequisites

- Configuration Tasks

- Configuration Example

- Command Reference

Feature Overview

The dialer software in Cisco IOS prior to Release 12.2(8)T had no way to dial two different destinations with the same IP address. More specifically, in networks where a network access server (NAS) supports dialing clients with overlapping addresses, dial-out attempts would fail. The Asynchronous Line Monitoring feature feature solves this problem.

A VRF—virtual routing and forwarding instance—is a per-Virtual Private Network (VPN) routing information repository that defines the VPN membership of a customer site attached to the NAS. A VRF consists of an IP routing table, a derived Cisco Express Forwarding (CEF) table, a set of interfaces that use the forwarding table, and a set of rules and routing protocol parameters that control the information that is included in the routing table. A separate set of routing and CEF tables is maintained for each VPN customer.

The Multiprotocol Label Switching (MPLS) distribution protocol is a high-performance packet forwarding technology that integrates the performance and traffic management capabilities of data link layer switching with the scalability, flexibility, and performance of network-layer routing.

, which have been enhanced to include VRF information.

command to determine the telephone number to be dialed.

commands that correspond to that particular VRF are used to determine the destination interface.

Benefits

The Asynchronous Line Monitoring feature feature allows the dialer software to dial out in an MPLS-based VPN. The MPLS VPN model simplifies network routing. For example, rather than needing to manage routing over a complex virtual network backbone composed of many virtual circuits, an MPLS VPN user can employ the backbone of the service provider as the default route in communicating with all other VPN sites.

This default route capability allows several sites to transparently interconnect through the service provider network. One service provider network can support several different IP VPNs, each of which appears to its users as a separate, private network. Within a VPN, each site can send IP packets to any other site in the same VPN, because each VPN is associated with one or more VRFs. The VRF is a key element in the VPN technology, because it maintains the routing information that defines a customer VPN site.

For additional benefits and information about MPLS, VPNs, and VRF, refer to the documents listed in the “Related Documents” section.

Related Documents

Additional information about configuring networks that can take advantage of the Asynchronous Line Monitoring feature feature can be found in the following Cisco IOS documentation:

- Cisco IOS Dial Technologies Command Reference , Release 12.2.

- Cisco IOS Dial Technologies Configuration Guide , Release 12.2. Refer to the chapter “Configuring Virtual Profiles” in the part “Virtual Templates, Profiles, and Networks.”

- Cisco IOS Switching Services Command Reference , Release 12.2.

- Cisco IOS Switching Services Configuration Guide , Release 12.2. Refer to the chapters “Multiprotocol Label Switching Overview” and “Configuring Multiprotocol Label Switching” in the part “Multiprotocol Label Switching.”

Supported Platforms

The Asynchronous Line Monitoring feature feature is supported on the following Cisco router and access server platforms:

- Cisco 1600 series

- Cisco 1720

- Cisco 1721

- Cisco 1750

- Cisco 1751

- Cisco 3600 series

- Cisco 3631

- Cisco 3725

- Cisco 3745

- Cisco 7200 series

- Cisco 7500 series

- Cisco 802

- Cisco 820

- Cisco 828

- Cisco uBR7200

Determining Platform Support Through Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Feature Navigator. Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image.

.

Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Feature Navigator home page at the following URL:

Supported Standards, MIBs, and RFCs

Standards

None

MIBs

None

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

RFCs

None

Prerequisites

Before beginning the tasks described in this document, you need to understand how to configure the following network features:

- Virtual profiles with two-way AAA authentication

- MPLS VPNs

Refer to the documents listed in the “Related Documents” section for information about configuring these features.

Configuration Tasks

See the following sections for the configuration tasks for this feature. Each task in the list is identified as either required or optional.

- Configuring Asynchronous Line Monitoring feature (required)

- Verifying Asynchronous Line Monitoring feature (optional)

Configuring Asynchronous Line Monitoring feature

To map a VRF and next hop address combination to a dial string and thereby allow the dialer software to be VRF-aware for an MPLS VPN, use the following commands beginning in global configuration mode.

Command

Purpose

Step 1

Enters configuration mode and begins dialer configuration.

Step 2

Maps a VRF and next hop address combination to a dial string (telephone number).

Step 3

Exit to global configuration mode.

Step 4

Configures a VRF and next hop address combination that points to the interface where the dialer software should make the connection.

These commands are only part of the required configuration and show how to map a VRF and next hop address combination to a dial string. Refer to the documents listed in the section “Related Documents” and the example in the “Configuration Example” section, for details on where to include these commands in the network configuration.

Verifying Asynchronous Line Monitoring feature

The verification process described in this section is based on the following configuration:

interface dialer 1

dialer map ip 10.0.0.1 vrf blue name peer1 peer1_number

ip route vrf blue 10.0.0.1 255.255.255.255 Dialer0

EXEC command to check CEF adjacency table information.

Troubleshooting Tips

privileged EXEC commands on the NAS to help you determine where the problem lies:

- debug ppp authentication

- debug ppp negotiation

- debug aaa authentication

- debug aaa authorization

- debug radius

- debug dialer

Monitoring and Maintaining Asynchronous Line Monitoring feature

To monitor and maintain the Asynchronous Line Monitoring feature feature, use the following EXEC commands:

Command

Purpose

Displays CEF adjacency table information.

Displays all static IP routes, or those installed using the AAA route download function.

Displays information about the active lines on the router.

Configuration Example

This section provides a configuration example of the Asynchronous Line Monitoring feature feature on the simple network topology shown in Figure 1.

Figure 1 CE-to-PE-to-Peer MPLS VPN Topology

Note The network addresses and telephone numbers used in the following configuration are examples only and will not work if tried in an actual network configuration.

Customer Edge (CE) Router

!

hostname oaktree02

enable secret 5 !1!35Fg$Ep4.D8JGpg7rKxQa49BF9/

!

!

ip subnet-zero

no ip domain-lookup

!

!

controller T1 5/0

!

controller T1 5/1

!

!

!

interface FastEthernet0/0

no ip address

no ip mroute-cache

duplex auto

speed auto

!

interface FastEthernet0/1

no ip address

no ip mroute-cache

shutdown

duplex auto

speed auto

!

interface Ethernet1/0

ip address 10.0.58.11 255.255.255.0

no ip mroute-cache

half-duplex

!

interface Ethernet1/1

ip address 50.0.0.2 255.0.0.0

no ip mroute-cache

half-duplex

!

interface Ethernet1/2

no ip address

no ip mroute-cache

shutdown

half-duplex

!

interface Ethernet1/3

no ip address

no ip mroute-cache

shutdown

half-duplex

!

interface Serial2/0

no ip address

no ip mroute-cache

shutdown

no fair-queue

serial restart-delay 0

!

interface Serial2/1

no ip address

no ip mroute-cache

shutdown

serial restart-delay 0

!

interface Serial2/2

no ip address

no ip mroute-cache

shutdown

serial restart-delay 0

!

interface Serial2/3

no ip address

no ip mroute-cache

shutdown

serial restart-delay 0

!

interface Serial3/0

no ip address

no ip mroute-cache

shutdown

!

interface Serial3/1

no ip address

no ip mroute-cache

shutdown

!

interface Serial3/2

no ip address

no ip mroute-cache

shutdown

!

interface Serial3/3

no ip address

no ip mroute-cache

shutdown

!

interface Serial3/4

no ip address

no ip mroute-cache

shutdown

!

interface Serial3/5

no ip address

no ip mroute-cache

shutdown

!

interface Serial3/6

no ip address

no ip mroute-cache

shutdown

!

interface Serial3/7

no ip address

no ip mroute-cache

shutdown

!

interface FastEthernet4/0

no ip address

no ip mroute-cache

shutdown

duplex auto

speed auto

!

ip classless

ip route 0.0.0.0 0.0.0.0 10.0.58.1

ip route 60.0.0.0 255.0.0.0 50.0.0.1

no ip http server

!

!

snmp-server manager

banner motd ^C AV-8B OAKTREE^C

alias exec r sh run

!

line con 0

exec-timeout 0 0

line aux 0

login

line vty 0 4

no login

!

end

Provider’s Edge (PE) Router

!

hostname pinetree02

!

aaa new-model

!

!

aaa authentication login con-log none

aaa authentication ppp default group radius

aaa authorization network default group radius

aaa session-id common

enable secret 5 $1$7KlA$xpC8l4dJCZogbzZvGUtFl/

!

username rubbertree02 password 0 Hello

ip subnet-zero

!

!

no ip domain-lookup

!

!

ip vrf yellow

rd 100:1

ip cef

virtual-profile aaa

isdn switch-type primary-5ess

!

!

!

controller T1 3/0

framing esf

linecode b8zs

pri-group timeslots 1-24

!

controller T1 3/1

framing esf

linecode b8zs

!

controller T1 3/2

framing esf

linecode b8zs

!

controller T1 3/3

framing esf

linecode b8zs

!

controller T1 3/4

framing esf

linecode b8zs

!

controller T1 3/5

framing esf

linecode b8zs

!

controller T1 3/6

framing esf

linecode b8zs

!

controller T1 3/7

framing esf

linecode b8zs

!

!

interface Loopback0

ip vrf forwarding yellow

ip address 70.0.0.1 255.0.0.0

!

interface FastEthernet1/0

no ip address

shutdown

duplex half

!

interface Ethernet2/0

ip address 10.0.58.3 255.255.255.0

duplex full

!

interface Ethernet2/1

ip vrf forwarding yellow

ip address 50.0.0.1 255.0.0.0

duplex half

!

interface Ethernet2/2

no ip address

shutdown

duplex half

!

interface Ethernet2/3

no ip address

shutdown

duplex half

!

interface Serial3/0:23

description phone# 555-3123

no ip address

encapsulation ppp

dialer rotary-group 0

dialer-group 1

isdn switch-type primary-5ess

ppp authentication chap

!

interface Serial4/0

no ip address

shutdown

no fair-queue

!

interface Serial4/1

no ip address

shutdown

!

interface Serial4/2

no ip address

shutdown

!

interface Serial4/3

no ip address

shutdown

!

interface Dialer0

ip address negotiated

encapsulation ppp

dialer in-band

dialer map ip 60.0.0.12 vrf yellow name rubbertree02 5552171

dialer map ip 60.0.0.2 5552172

dialer-group 1

ppp authentication chap

!

ip classless

ip route 0.0.0.0 0.0.0.0 10.0.58.1

ip route 60.0.0.2 255.255.255.255 Dialer0

ip route vrf yellow 60.0.0.0 255.0.0.0 Dialer0 permanent

no ip http server

ip pim bidir-enable

!

ip director cache time 60

dialer-list 1 protocol ip permit

!

!

!

radius-server host 172.19.192.89 auth-port 1645 acct-port 1646 key rad123

radius-server retransmit 3

call rsvp-sync

!

no mgcp timer receive-rtcp

!

mgcp profile default

!

dial-peer cor custom

!

!

!

gatekeeper

shutdown

!

banner motd ^C F/A-18 PINETREE ^C

!

line con 0

exec-timeout 0 0

login authentication con-log

line aux 0

line vty 5 15

!

!

end

Peer Router

!

hostname rubbertree02

!

logging buffered 32000 debugging

enable secret 5 $1$RCKC$scgtdlaDzjSyUVAi7KK5Q.

enable password Windy

!

username pinetree02 password 0 Hello

!

!

!

ip subnet-zero

no ip domain-lookup

!

isdn switch-type basic-5ess

!

!

!

interface Ethernet0

ip address 10.0.58.9 255.255.255.0

no ip route-cache

!

interface Serial0

no ip address

no ip route-cache

shutdown

!

interface BRI0

description phone# 555-2171

ip address 60.0.0.12 255.0.0.0

encapsulation ppp

no ip route-cache

dialer map ip 60.0.0.11 5553123

dialer map ip 60.0.0.2 5552172

dialer-group 1

isdn switch-type basic-5ess

isdn fast-rollover-delay 45

!

ip default-gateway 10.0.58.1

ip classless

ip route 0.0.0.0 0.0.0.0 10.0.58.1

ip route 50.0.0.0 255.0.0.0 70.0.0.1

no ip http server

!

dialer-list 1 protocol ip permit

no cdp run

banner motd ^C F-4B RUBBERTREE^C

!

line con 0

exec-timeout 0 0

line vty 0 4

password Windy

login

!

end

AAA Server User File

[aaa-serv]/usr/testing/bin> ./radiusd_1.16 -d . -a . -x

greentree-16 Password = "Hello", Expiration = "Dec 31 2005"

Service-Type = Framed-User,

Framed-Protocol = PPP

cisco-avpair = "lcp:interface-config=ip vrf forwarding yellow \nip

unnumbered Loopback0"

Command Reference

- dialer map

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007–2009 Cisco Systems, Inc. All rights reserved.

Dialer Persistent

Feature History

Release

Modification

12.2(4)T

This feature was introduced.

12.2(11)T

This feature was implemented on Cisco access server platforms.

This document describes the Dialer Persistent feature. It includes the following sections.

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Prerequisites

- Configuration Tasks

- Monitoring and Maintaining Dialer Persistence

- Configuration Examples

- Command Reference

- Glossary

Feature Overview

command starts a timer when the dialer interface starts up and starts the connection when the timer expires. If interesting traffic arrives before the timer expires, the connection is still brought up and set as persistent. The command provides a default timer interval, or you can set a custom timer interval.

interface command is entered on the dialer interface. If the persistent connection is torn down for some other reason, such as the ISDN line goes down, the system immediately tries to bring the connection back up, and will use any other settings configured for dialing on the dialer interface.

Benefits

interface command is entered on the dialer interface.

Until Cisco IOS Release 12.2(4)T, interesting traffic was used to bring up a DDR link. If there was no interesting traffic and the idle timeout interval was reached, the link was torn down. However, there are situations where a link needs to be up all the time. The Dialer Persistent feature provides the option to ignore idle timers and interesting traffic, thereby keeping the link up and maintaining DDR dialed calls indefinitely. The Dialer Persistent feature allows you to configure the intervals to be used for dial attempts, both initially on startup and when a persistent link is brought down due to external failures.

Restrictions

The Dialer Persistent feature is available only with dialer profiles and not with legacy dialers.

command is configured.

Related Documents

- Cisco IOS Dial Technologies Command Reference , Release 12.2

- Cisco IOS Dial Technologies Configuration Guide , “Dial-on-Demand Routing Configuration” part, Release 12.2

Supported Platforms

See the next section for information about Feature Navigator and how to use this tool to determine the platforms and software images in which this feature is available.

Platform Support Through Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Feature Navigator. Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image.

To access Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions at http://www.cisco.com/register.

Feature Navigator is updated when major Cisco IOS software releases and technology releases occur. As of May 2001, Feature Navigator supports M, T, E, S, and ST releases. You can access Feature Navigator at the following URL:

http://www.cisco.com/go/fn

Supported Standards, MIBs, and RFCs

Standards

None

MIBs

None

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

RFCs

None

Prerequisites

, “Dial-on-Demand Routing Configuration” part, Release 12.2.

Configuration Tasks

See the following sections for configuration tasks for the Dialer Persistent feature. Each task in the list is identified as either required or optional:

- Configuring Dialer Persistent (required)

- Shutting Down an Interface Configured for Dialer Persistence (required)

- Verifying Dialer Persistent (optional)

The section “Monitoring and Maintaining Dialer Persistence” describes how to monitor and maintain the Dialer Persistent feature. See the section“Configuration Examples” for an example of how to configure the Dialer Persistent feature.

Configuring Dialer Persistent

To configure a dialer interface as persistent, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Creates a dialer interface and enters interface configuration mode.

Step 2

Specifies the IP address and mask of the dialer interface as a node in the destination network to be called.

Step 3

Specifies the encapsulation type.

Step 4

Specifies the remote destination to call and the map class that defines characteristics for calls to this destination.

Step 5

Specifies the dialing pool to use for calls to this destination.

Step 6

Assigns the dialer interface to a dialer group.

Step 7

Specifies an access list by list number or by protocol and list number to define the interesting packets that can trigger a call.

Step 8

(Optional) Specifies the authentication name of the remote router on the destination subnetwork for a dialer interface.

Step 9

]

Forces a dialer interface to be connected at all times, even in the absence of interesting traffic.

command reference page for additional commands that might be entered for this configuration.

Shutting Down an Interface Configured for Dialer Persistence

To fully tear down (shut down) a dialer interface configured for dialer persistent, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Enters interface configuration mode on the specified dialer interface.

Step 2

Fully tears down a persistent connection and prevents the software from attempting more dialing.

Verifying Dialer Persistent

To verify that dialer persistent is configured correctly, perform the following verification steps:

EXEC command with the interface type and number to display statistics on the physical interface bound to the dialer interface. Output includes the configured timers. The “Idle timer (never)” and “Dial reason:” lines indicate that persistent dialing is configured.

Router# show dialer interface dialer 1

Di1 - dialer type = DIALER PROFILE

Idle timer (never), Fast idle timer (20 secs)

Wait for carrier (30 secs), Re-enable (15 secs)

Dialer state is data link layer up

Number of active calls = 1

Dial String Successes Failures Last DNIS Last status

7135551234 4 0 00:00:06 successful Default

BRI1/0 - dialer type = ISDN

Dial String Successes Failures Last DNIS Last status

0 incoming call(s) have been screened.

0 incoming call(s) rejected for callback.

BRI1/0:2 - dialer type = ISDN

Idle timer (never), Fast idle timer (20 secs)

Wait for carrier (30 secs), Re-enable (15 secs)

Dialer state is data link layer up

Dial reason: Dialing on persistent Dialer Profile

Interface bound to profile Di1

Time until disconnect never

Current call connected 00:00:06

Connected to 7135550134 (7135550134)

EXEC command and verify that the following message appears:

Di1 DDR: Persistent Dialer Profile nailed up successfully

Monitoring and Maintaining Dialer Persistence

To monitor and maintain a dialer interface configured for dialer persistent, use the following commands in EXEC mode, as needed:

Command

Purpose

Router# clear interface

command clears unsuccessful dial attempts on a line without interesting traffic, and then the dialer software attempts to bring up the connection as persistent.

Router# debug dialer

Displays debugging information about the packets received on a dialer interface.

Configuration Examples

This section provides the following Dialer Persistent configuration examples:

- Standard Dialer Persistent Configuration Example

- Dialer Persistent Plus Failed Connection Delays Configuration Example

Standard Dialer Persistent Configuration Example

The following example shows how to configure a 5-second initial delay before the persistent connection is established:

!

interface dialer 1

ip address negotiated

encapsulation ppp

dialer pool 1

dialer remote-name remote1

dialer idle-timeout 0 either

dialer string 7135550199

dialer persistent delay initial 5

ppp authentication chap

ppp chap hostname DDR

ppp chap password secret

!

ip classless

ip route 0.0.0.0 0.0.0.0 dialer 1

ip route 172.30.21.0 255.255.255.0 1.1.1.5

ip route 172.30.114.0 255.255.255.0 172.30.21.1

no ip http server

!

!

map-class dialer test

dialer isdn speed 56

access-list 183 permit ip host 10.239.28.2 host 10.239.28.128

access-list 183 permit ip host 10.239.28.128 host 10.239.28.2

!

Dialer Persistent Plus Failed Connection Delays Configuration Example

The following example shows how to configure a 1-minute delay at boot-up, and a 10-second delay for redialing after a failed connection with a maximum of five tries before stopping:

!

interface dialer 1

ip address negotiated

encapsulation ppp

dialer pool 1

dialer remote-name remote1

dialer idle-timeout 0 either

dialer string 7135550199

dialer persistent delay initial 60

dialer persistent delay 10

dialer persistent max-attempts 5

ppp authentication chap

ppp chap hostname DDR

ppp chap password mysecret

!

ip classless

ip route 0.0.0.0 0.0.0.0 dialer 1

ip route 172.30.21.0 255.255.255.0 1.1.1.5

ip route 172.30.114.0 255.255.255.0 172.30.21.1

no ip http server

!

!

map-class dialer test

dialer isdn speed 56

access-list 183 permit ip host 10.239.28.2 host 10.239.28.128

access-list 183 permit ip host 10.239.28.128 host 10.239.28.2

!

Command Reference

.

- dialer persistent

Glossary

.

interface configuration command is entered on the interface.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007–2009 Cisco Systems, Inc. All rights reserved.

PPPoE Client DDR Idle-Timer

The PPPoE Client DDR Idle-Timer feature supports the dial-on-demand routing (DDR) interesting traffic control list functionality of the dialer interface with a PPP over Ethernet (PPPoE) client, but also keeps original functionality (PPPoE connection up and always on after configuration) for those PPPoE clients that require it.

Feature Specifications for the PPPoE Client DDR Idle-Timer Feature

Feature History

Release

Modification

12.2(13)T

This feature was introduced.

Finding Support Information for Platforms and Cisco IOS Software Images

at the login dialog box and follow the instructions that appear.

Contents

- Prerequisites for Using the PPPoE Client DDR Idle-Timer

- Information About the PPPoE Client DDR Idle-Timer

- How to Configure the PPPoE Client DDR Idle-Timer

- Configuration Examples for PPPoE Client DDR Idle-Timer

- Additional References

- Command Reference

Prerequisites for Using the PPPoE Client DDR Idle-Timer

Before configuring the PPPoE Client DDR Idle-Timer feature, you must understand the concept of DDR interesting packets and access control lists and PPPoE Stage Protocols. See the “Additional References” section for links to the documents describing these concepts.

Information About the PPPoE Client DDR Idle-Timer

To configure the PPPoE client DDR idle-timer, you need to understand the following concept:

- DDR Functionality and the PPPoE Client

DDR Functionality and the PPPoE Client

Before Cisco IOS Release 12.2(13)T, the DDR interesting traffic control list functionality of the dialer interface was not supported for PPPoE. However, the PPPoE Client DDR Idle-Timer feature, available as part of Cisco IOS Release 12.2(13)T, now supports this DDR functionality for a PPPoE client.

. Packets that do not match a permit entry or that do match a deny entry are deemed uninteresting. When a packet is found to be interesting, either the dialer idle timer is reset (if the line is active) or a connection is attempted (assuming the line is available but not active). If a tested packet is deemed uninteresting, it will be forwarded if it is intended for a destination known to be on a specific interface and the link is active. However, such a packet will not initiate a DDR call and will not reset the idle timer. If dialer idle timer expires, the dialer interface calls a PPPoE function to tear down the connection.

, allows configuring a DDR interesting traffic control list for PPPoE connections, but also keeps original connection functionality for those PPPoE clients that require it. If you do not require DDR, the PPPoE connection will be up and always on after configuration. If you do require DDR functionality, the connection will be brought up when interesting traffic comes in from the LAN interface and brought down after the dialer idle timer expires. Interesting traffic that comes from WAN interface will only reset the dialer idle timer.

Protocol access lists and dialer access lists have already been implemented in the dialer interface for the operation of DDR. For a PPPoE client, access lists are used as the screening criteria for determining if PPPoE Discovery initiation or a dialer idle timer reset is needed. But a protocol access list is not required for this feature; it depends on your network needs. An access-list can be configured and associated with dialer-list, or you can configure only the dialer list.

All packets destined to the dialer interface are tested against the dialer access list. Packets that match a permit entry are deemed interesting. Packets that do not match a permit entry or that do match a deny entry are deemed uninteresting. When a packet is found to be interesting, the dialer idle timer will be reset if the PPPoE session has already been set up, or a PPPoE Discovery will be attempted if there is no PPPoE session. If a tested packet is deemed uninteresting, it will not initiate PPPoE Discovery and will not reset the idle timer.

How to Configure the PPPoE Client DDR Idle-Timer

This section contains the following procedures. Each procedure is identified as either required or optional.

- Configure the PPPoE Client DDR Idle-Timer on an ATM PVC Interface (required)

- Configure the PPPoE Client DDR Idle-Timer on an Ethernet Interface (required)

- Configure the Dialer Interface (required)

Configure the PPPoE Client DDR Idle-Timer on an ATM PVC Interface

To configure the PPPoE client DDR idle-timer in interface-ATM-VC configuration mode, use the following commands:

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables higher privilege levels, such as privileged EXEC mode.

- Enter your password if prompted.

Step 2

}

Router# configure terminal

Enters global configuration mode.

Step 3

Router# interface atm 2/0

Configures an ATM interface type and enters interface configuration mode.

Step 4

Router(config-if)# pvc 2/100

Creates an ATM permanent virtual circuit (PVC) and enters interface-ATM-VC configuration mode.

Step 5

Router(config-if-atm-vc)# pppoe-client dial-pool-number 1 dial-on-demand

Configures DDR interesting traffic control list functionality of the dialer interface with a PPPoE client.

- The optional dial-on-demand keyword enables DDR functionality on the PPPoE connection.

Step 6

Router(config-if-atm-vc)# exit

Exits the configuration mode.

- Enter the exit command at each configuration mode to leave that mode.

What to Do Next

be configured. See the “Configure the Dialer Interface” section for the steps to do this.

Configure the PPPoE Client DDR Idle-Timer on an Ethernet Interface

To configure the PPPoE client DDR idle-timer on an Ethernet interface, use the following commands:

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables higher privilege levels, such as privileged EXEC mode.

- Enter your password if prompted.

Step 2

}

Router# configure terminal

Enters global configuration mode.

Step 3

Router# interface ethernet 1

Configures an Ethernet interface and enters interface configuration mode.

Step 4

Router(config-if)# pppoe enable

Enables PPPoE sessions on an Ethernet interface.

Step 5

Router(config-if)# pppoe-client dial-pool-number 1 dial-on-demand

Configures DDR interesting traffic control list functionality of the dialer interface with a PPPoE client.

- The optional dial-on-demand keyword enables DDR functionality on the PPPoE connection.

Step 6

Router(config-if-atm-vc)# exit

Exits the configuration mode.

- Enter the exit command at each configuration mode to leave that mode.

What to Do Next

be configured. See the “Configure the Dialer Interface” section for the steps to do this.

Configure the Dialer Interface

command), you must also configure the following commands:

SUMMARY STEPS

]

]

}

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables higher privilege levels, such as privileged EXEC mode.

- Enter your password if prompted.

Step 2

}

Router# configure terminal

Enters global configuration mode.

Step 3

Router# interface dialer 1

Defines a dialer rotary group and enters interface configuration mode.

Step 4

]

Router(config-if)# dialer idle-timeout 180 either

Specifies the duration of idle time before a line is disconnected.

- inbound —Only inbound traffic will reset the idle timeout.

- either —Both inbound and outbound traffic will reset the idle timeout.

Step 5

]

Router(config-if)# dialer hold-queue 100

Allows interesting outgoing packets to be queued until a modem connection is established.

- timeout —Amount of time, in seconds, to queue the packets.

Step 6

Router(config-if)# dialer-group 1

Controls access by configuring an interface to belong to a specific dialing group.

Step 7

Router(config-if)# exit

Leaves interface configuration mode and returns to global configuration mode.

Step 8

}

Router(config)# dialer-list 1 protocol ip permit

Defines a DDR dialer list for dialing by protocol or by a combination of a protocol and a previously defined access list.

- permit and deny —Configure access permissions.

- list —Specifies that an access list will be used for defining a granularity finer than an entire protocol.

Configuration Examples for PPPoE Client DDR Idle-Timer

command are included in the following client configuration examples:

- PPPoEoA Client Configuration Example

- PPPoEoE Client Configuration Example

PPPoEoA Client Configuration Example

The following example shows how to configure the PPPoE client DDR idle-timer on an ATM PVC interface:

!

vpdn enable

no vpdn logging

!

vpdn-group 1

request-dialin

protocol pppoe

!

interface ATM2/0

pvc 2/100

pppoe-client dial-pool-number 1 dial-on-demand

!

interface Dialer1

ip address negotiated

ip mtu 1492

encapsulation ppp

dialer pool 1

dialer idle-timeout 180 either

dialer hold-queue 100

dialer-group 1

!

dialer-list 1 protocol ip permit

!

ip route 0.0.0.0 0.0.0.0 Dialer1

PPPoEoE Client Configuration Example

The following example shows how to configure the PPPoE client DDR idle-timer on an Ethernet interface:

!

vpdn enable

no vpdn logging

!

vpdn-group 1

request-dialin

protocol pppoe

!

interface Ethernet1

pppoe enable

pppoe-client dial-pool-number 1 dial-on-demand

!

interface Dialer1

ip address negotiated

ip mtu 1492

encapsulation ppp

dialer pool 1

dialer idle-timeout 180 either

dialer hold-queue 100

dialer-group 1

!

dialer-list 1 protocol ip permit

!

ip route 0.0.0.0 0.0.0.0 Dialer1

Additional References

For additional information related to the PPPoE client DDR idle-timer, refer to the following references:

Related Documents

Related Topic

Document Title

DDR interesting packets and access control lists

. See the section “Configuring Access Control for Outgoing Calls “ in the chapter “Configuring Legacy DDR Hubs.”

DDR and dialer commands: complete command syntax, command mode, defaults, usage guidelines, and examples

.

PPPoE Client DDR Idle-Timer

.

PPPoE configuration commands: complete command syntax, command mode, defaults, usage guidelines, and example

.

Standards

Standards

Title

None

—

MIBs

MIBs

MIBs Link

None

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

x

If Cisco MIB Locator does not support the MIB information that you need, you can also obtain a list of supported MIBs and download MIBs from the Cisco MIBs page at the following URL:

To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:

RFCs

RFCs

Title

None

Technical Assistance

Description

Link

Technical Assistance Center (TAC) home page, containing 30,000 pages of searchable technical content, including links to products, technologies, solutions, technical tips, tools, and lots more. Registered Cisco.com users can log in from this page to access even more content.

Command Reference

.

- pppoe-client dial-pool-number

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007–2009 Cisco Systems, Inc. All rights reserved.

Redial Enhancements

Feature History

Release

Modification

12.2(4)T

This feature was introduced.

12.2(4)T2

Support for the Cisco 7500 series routers was added.

This document describes the Redial Enhancements feature for Cisco IOS Release 12.2(4)T. It includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Configuration Tasks

- Configuration Examples

- Command Reference

Feature Overview

The Redial Enhancements feature improves the performance of redial and provides greater control over redial behavior. The dialer will now cycle through all matching dialer strings or dialer maps before applying the redial interval, and may select a different physical dialer on each redial attempt. New dial-out attempts will not be initiated if a redial to the same destination is pending. The dialer can now be configured to apply a disable timer without performing any redial attempts, and a disable time can be applied to a dialer profile interface and to a serial dialer.

By default, the Cisco IOS software considers a call successful if it connects at the physical layer (Layer 1 of the OSI reference model). However, problems such as poor quality telco circuits or peer misconfiguration can cause dial-out failure even though a connection is made at the physical layer. The Redial Enhancements feature introduces a new command that allows the router to be configured to wait a specific amount of time for a line protocol to come up before considering a dial-out attempt successful. If the timer runs out or the call is dropped before the line protocol comes up, the call is considered unsuccessful. Unsuccessful dial-out attempts will trigger redial if the redial options have been configured.

Benefits

The Redial Enhancements feature will reduce dialer congestion by preventing additional dial-out attempts to any locations which have a redial attempt pending. This can reduce your telco bills by limiting unecessary dial-out attempts. In addition, the router may now be configured to wait for the line protocol to come up before considering a dial-out attempt successful.

Restrictions

command is supported only with the PPP encapsulation protocol.

Related Documents

- Cisco IOS Dial Technologies Configuration Guide , Release 12.2

- Cisco IOS Dial Technologies Command Reference , Release 12.2

Supported Platforms

- Cisco 800 series

- Cisco 1000 series

- Cisco 1600 series

- Cisco 2500 series

- Cisco 2600 series

- Cisco 3600 series

- Cisco 7200 series

- Cisco 7500 series

Platform Support Through Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Feature Navigator. Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image.

To access Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, e-mail the Contact Database Administration group at cdbadmin@cisco.com. If you want to establish an account on Cisco.com, go to http://www.cisco.com/register and follow the directions to establish an account.

Feature Navigator is updated when major Cisco IOS software releases and technology releases occur. As of May 2001, Feature Navigator supports M, T, E, S, and ST releases. You can access Feature Navigator at the following URL:

http://www.cisco.com/go/fn

Supported Standards, MIBs, and RFCs

Standards

No new or modified standards are supported by this feature.

MIBs

No new or modified MIBs are supported by this feature.

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

RFCs

No new or modified RFCs are supported by this feature.

Configuration Tasks

See the following sections for configuration tasks for the Redial Enhancements feature. Each task in the list is identified as either required or optional:

- Configuring Redial Options (optional)

- Configuring the Dialer to Wait for a Line Protocol (optional)

- Verifying Redial Configuration (optional)

Configuring Redial Options

To configure redial options, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Enters interface configuration mode.

Step 2

Configures redial options on the router.

Configuring the Dialer to Wait for a Line Protocol

To configure the router to wait for a line protocol after connecting to the physical layer, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Enters interface configuration mode.

Step 2

Configures the router to wait for a line protocol after connecting to the physical layer.

Verifying Redial Configuration

To verify the configuration of redial options, perform the following steps:

Step 1 Initiate a dial-out attempt to a location that is likely to fail to connect on the first attempt.

command. The following debug output results from a dial-out attempt that failed to connect on both the initial attempt and two redial attempts:

Target IP address:10.0.0.2

Repeat count [5]:1

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:

*Mar 1 02:26:52.567:BR0/0 DDR:rotor dialout [priority]

*Mar 1 02:26:52.567:BR0/0 DDR:Dialing cause ip (s=10.0.0.1, d=10.0.0.2)

*Mar 1 02:26:52.567:BR0/0 DDR:Attempting to dial 6109

*Mar 1 02:26:52.739:BRI0/0:wait for isdn carrier timeout, call id=0x800B

*Mar 1 02:26:52.739:Di1 DDR:Redial:Created for ip (s=10.0.0.1, d=10.0.0.2).

!This is new debug output specific to redial configuration.

Success rate is 0 percent (0/1)

led#

*Mar 1 02:27:22.739:Di1 DDR:Redial:Timeout

!This is new debug output specific to redial configuration.

*Mar 1 02:27:22.739:BR0/0 DDR:rotor dialout [priority]

*Mar 1 02:27:22.739:Di1 DDR:Redialing on BR0/0 for ip (s=10.0.0.1, d=10.0.0.2) (attempt 1)

!This is new debug output specific to redial configuration.

*Mar 1 02:27:22.739:BR0/0 DDR:Dialing cause ip (s=10.0.0.1, d=10.0.0.2)

*Mar 1 02:27:22.739:BR0/0 DDR:Attempting to dial 6109

*Mar 1 02:27:22.939:BRI0/0:wait for isdn carrier timeout, call id=0x800C

led#

*Mar 1 02:27:52.939:Di1 DDR:Redial:Timeout

!This is new debug output specific to redial configuration.

*Mar 1 02:27:52.939:BR0/0 DDR:rotor dialout [priority]

*Mar 1 02:27:52.939:Di1 DDR:Redialing on BR0/0 for ip (s=10.0.0.1, d=10.0.0.2) (attempt 2)

!This is new debug output specific to redial configuration.

*Mar 1 02:27:52.939:BR0/0 DDR:Dialing cause ip (s=10.0.0.1, d=10.0.0.2)

*Mar 1 02:27:52.939:BR0/0 DDR:Attempting to dial 6109

*Mar 1 02:27:53.135:BRI0/0:wait for isdn carrier timeout, call id=0x800D

*Mar 1 02:27:53.139:Di1 DDR:Redial:Removed for ip (s=10.0.0.1, d=10.0.0.2) (2 attempts tried)

!This is new debug output specific to redial configuration.

led#

led#

The following debug output results from a dial-out attempt that failed to connect initially, but succeeded on the first redial attempt:

Router# ping

Protocol [ip]:

Target IP address:10.0.0.2

Repeat count [5]:1

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:

*Mar 1 02:28:47.095:BR0/0 DDR:rotor dialout [priority]

*Mar 1 02:28:47.099:BR0/0 DDR:Dialing cause ip (s=10.0.0.1, d=10.0.0.2)

*Mar 1 02:28:47.099:BR0/0 DDR:Attempting to dial 6109

*Mar 1 02:28:47.287:BRI0/0:wait for isdn carrier timeout, call id=0x800E

*Mar 1 02:28:47.287:Di1 DDR:Redial:Created for ip (s=10.0.0.1, d=10.0.0.2).

!This is new debug output specific to redial configuration.

Success rate is 0 percent (0/1)

led#

*Mar 1 02:29:17.287:Di1 DDR:Redial:Timeout

!This is new debug output specific to redial configuration.

*Mar 1 02:29:17.287:BR0/0 DDR:rotor dialout [priority]

*Mar 1 02:29:17.287:Di1 DDR:Redialing on BR0/0 for ip (s=10.0.0.1, d=10.0.0.2) (attempt 1)

!This is new debug output specific to redial configuration.

*Mar 1 02:29:17.287:BR0/0 DDR:Dialing cause ip (s=10.0.0.1, d=10.0.0.2)

*Mar 1 02:29:17.287:BR0/0 DDR:Attempting to dial 6109

02:29:77309411327:%LINK-3-UPDOWN:Interface BRI0/0:1, changed state to up

*Mar 1 02:29:17.487:Di1 DDR:Redial:Upon call connection

!This is new debug output specific to redial configuration.

*Mar 1 02:29:17.487:Di1 DDR:Redial:Removed for ip (s=10.0.0.1, d=10.0.0.2) (1 attempts tried)

!This is new debug output specific to redial configuration.

*Mar 1 02:29:17.487:BR0/0:1:interface must be fifo queue, force fifo

02:29:77309411327:%DIALER-6-BIND:Interface BR0/0:1 bound to profile Di1

*Mar 1 02:29:19.455:BR0/0:1 DDR:No callback negotiated

*Mar 1 02:29:19.471:BR0/0:1 DDR:dialer protocol up

02:29:20:%LINEPROTO-5-UPDOWN:Line protocol on Interface BRI0/0:1, changed state to up

led#

led#

command was configured to wait 10 seconds for the line protocol to come up.

Zcape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:

*Mar 1 02:32:08.631:BR0/0 DDR:rotor dialout [priority]

*Mar 1 02:32:08.631:BR0/0 DDR:Dialing cause ip (s=10.0.0.1, d=10.0.0.2)

*Mar 1 02:32:08.631:BR0/0 DDR:Attempting to dial 6109

02:32:35168336435:%LINK-3-UPDOWN:Interface BRI0/0:1, changed state to up

*Mar 1 02:32:08.787:BR0/0:1:interface must be fifo queue, force fifo

02:32:38654705663:%DIALER-6-BIND:Interface BR0/0:1 bound to profile Di1.....

Success rate is 0 percent (0/5)

led#

*Mar 1 02:32:18.787:BR0/0:1 DDR:wait for line protocol timeout

!This is new debug output specific to waiting for a line protocol to come up.

*Mar 1 02:32:18.787:BR0/0 DDR:has total 0 call(s), dial_out 0, dial_in 0

02:32:18:%DIALER-6-UNBIND:Interface BR0/0:1 unbound from profile Di1

*Mar 1 02:32:18.787:BR0/0:1 DDR:disconnecting call

*Mar 1 02:32:18.787:Di1 DDR:Redial:Created for ip (s=10.0.0.1, d=10.0.0.2)

!This is new debug output specific to redial configuration.

02:32:18:%ISDN-6-CONNECT:Interface BRI0/0:1 is now connected to 6109

02:32:18:%ISDN-6-DISCONNECT:Interface BRI0/0:1 disconnected from 6109 , call lasted 10 seconds

02:32:79471714404:%LINK-3-UPDOWN:Interface BRI0/0:1, changed state to down

*Mar 1 02:32:18.879:BR0/0:1 DDR:disconnecting call

led#

led#

*Mar 1 02:32:48.787:Di1 DDR:Redial:Timeout

!This is new debug output specific to redial configuration.

*Mar 1 02:32:48.787:BR0/0 DDR:rotor dialout [priority]

*Mar 1 02:32:48.787:Di1 DDR:Redialing on BR0/0 for ip (s=10.0.0.1, d=10.0.0.2) (attempt 1)

!This is new debug output specific to redial configuration.

*Mar 1 02:32:48.787:BR0/0 DDR:Dialing cause ip (s=10.0.0.1, d=10.0.0.2)

*Mar 1 02:32:48.787:BR0/0 DDR:Attempting to dial 6109

02:32:208317874112:%LINK-3-UPDOWN:Interface BRI0/0:1, changed state to up

*Mar 1 02:32:48.987:BR0/0:1:interface must be fifo queue, force fifo

02:32:210453397503:%DIALER-6-BIND:Interface BR0/0:1 bound to profile Di1

led#

*Mar 1 02:32:58.987:BR0/0:1 DDR:wait for line protocol timeout

!This is new debug output specific to waiting for a line protocol to come up.

*Mar 1 02:32:58.987:BR0/0 DDR:has total 0 call(s), dial_out 0, dial_in 0

02:32:58:%DIALER-6-UNBIND:Interface BR0/0:1 unbound from profile Di1

*Mar 1 02:32:58.987:BR0/0:1 DDR:disconnecting call

02:32:58:%ISDN-6-CONNECT:Interface BRI0/0:1 is now connected to 6109

02:32:58:%ISDN-6-DISCONNECT:Interface BRI0/0:1 disconnected from 6109 , call lasted 10 seconds

02:32:255565373540:%LINK-3-UPDOWN:Interface BRI0/0:1, changed state to down

*Mar 1 02:32:59.079:BR0/0:1 DDR:disconnecting call

led#

led#

*Mar 1 02:33:28.987:Di1 DDR:Redial:Timeout

!This is new debug output specific to redial configuration.

*Mar 1 02:33:28.987:BR0/0 DDR:rotor dialout [priority]

*Mar 1 02:33:28.987:Di1 DDR:Redialing on BR0/0 for ip (s=10.0.0.1, d=10.0.0.2) (attempt 2)

!This is new debug output specific to redial configuration.

*Mar 1 02:33:28.987:BR0/0 DDR:Dialing cause ip (s=10.0.0.1, d=10.0.0.2)

*Mar 1 02:33:28.987:BR0/0 DDR:Attempting to dial 6109

02:33:126713495488:%LINK-3-UPDOWN:Interface BRI0/0:1, changed state to up

*Mar 1 02:33:29.187:BR0/0:1:interface must be fifo queue, force fifo

02:33:128849018879:%DIALER-6-BIND:Interface BR0/0:1 bound to profile Di1

*Mar 1 02:33:31.155:BR0/0:1 DDR:No callback negotiated

*Mar 1 02:33:31.171:BR0/0:1 DDR:dialer protocol up

*Mar 1 02:33:31.171:Di1 DDR:Redial:Upon line protocol up

!This is new debug output specific to redial configuration.

*Mar 1 02:33:31.175:Di1 DDR:Redial:Removed for ip (s=10.0.0.1, d=10.0.0.2) (2 attempts tried)

!This is new debug output specific to redial configuration.

02:33:32:%LINEPROTO-5-UPDOWN:Line protocol on Interface BRI0/0:1, changed state to up

led#

Configuration Examples

This section provides the following configuration examples:

- Dialer Redial Example

- Dialer Wait-for-Line-Protocol Example

Dialer Redial Example

The following example configures redial options on the dialer:

dialer redial interval 10 attempts 5 re-enable 3000

Dialer Wait-for-Line-Protocol Example

The following example configures the dialer to wait for a line protocol after making a physical connection:

dialer wait-for-line-protocol 10

Command Reference

.

New Command

- dialer wait-for-line-protocol

Modified Command

- dialer redial

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 200–2009 Cisco Systems, Inc. All rights reserved.

Rotating Through Dial Strings

Feature History

Release

Modification

12.2(8)T

This feature was introduced.

This document describes the Asynchronous Line Monitoring feature feature in Cisco IOS Release 12.2(8)T and includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Prerequisites

- Configuration Tasks

- Configuration Examples

- Command Reference

Feature Overview

The Cisco IOS software allows multiple dial strings (telephone numbers) to be configured for outgoing calls. In previous releases of the Cisco IOS software, the dial string used for a particular outgoing call was always the first telephone number in the dial string list. It was not possible to customize the selection or otherwise participate in deciding which dial string should be used first. But in Cisco IOS Release 12.2(8)T, the Asynchronous Line Monitoring feature feature allows the order in which dial strings should be dialed to be specified.

Benefits

The Asynchronous Line Monitoring feature feature allows you to specify the dialing order when multiple dial strings are configured. Options for dialing order are as follows:

- Sequential—Dial using the first dial string configured in a list of multiple strings.

- Round-robin—Dial using the dial string following the most recently successful dial string.

- Last successful call—Dial using the most recently successful dial string.

This feature takes advantage of information available from a previous call attempt, such as the call was unsuccessful or the line was busy, and thereby increases the rate of successful calls.

Related Documents

, refer to the chapter “Configuring Peer-to-Peer DDR with Dialer Profiles” in the part “Dial-on-Demand Routing Configuration.” In the same manual, also refer to the chapter “Configuring ISDN Caller ID Callback,” in the part “Callback and Bandwidth Allocation Configuration.”

Supported Platforms

- Cisco 1400 series

- Cisco 1600 series

- Cisco 1710

- Cisco 1720

- Cisco 1721

- Cisco 1750

- Cisco 1751

- Cisco 2400 series

- Cisco 2600 series

- Cisco 3620

- Cisco 3631

- Cisco 3640

- Cisco 3660

- Cisco 3725

- Cisco 3745

- Cisco 7100

- Cisco 7200

- Cisco 7500

- Cisco 7700

- Cisco 800 series

- Cisco 805

- Cisco 806

- Cisco 828

- Cisco MC3810

- Universal Route Module (URM)

- ubr7200

Determining Platform Support Through Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Feature Navigator. Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image.

.

Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Feature Navigator home page at the following URL:

Supported Standards, MIBs, and RFCs

Standards

None

MIBs

None

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

RFCs

None

Prerequisites

configuration commands. See the documents listed in the “Related Documents” section for more information about using these commands to configure dial strings.

Configuration Tasks

See the following sections for the configuration tasks for this feature. Each task in the list is identified as either required or optional.

- Configuring the Order of Dial Strings (required)

- Verifying Dial String Order (optional)

Configuring the Order of Dial Strings

To specify the order in which dial strings should be dialed, use the following command in interface configuration mode:

Command

Purpose

]

Specifies the dialing order when multiple dial strings are configured. Use one of the following optional keywords:

- sequential —Starts dialing the first dial string configured in a list of multiple strings.

- round-robin —Starts dialing using the dial string that occurs after the most recently successful dial string.

- last-successful —Starts dialing using the most recently successful dial string.

command keywords can be configured on a per-interface basis. You can use this command in interface configurations that apply to both legacy dialers and dialer profiles. See the “Configuration Examples” section to see how this command is used with both these dialer types.

Verifying Dial String Order

To verify that the dial string order is configured correctly, perform the following step:

command with the appropriate interface type at the privileged EXEC prompt:

Router# show running-config interface dialer 1

Building configuration...

Current configuration : 96 bytes

!

interface Dialer1

no ip address

dialer pool 1

dialer order round-robin

no cdp enable

end

command is listed, that indicates the default sequential dial string order is configured.

command at the privileged EXEC prompt:

Router# show isdn history

Troubleshooting Tips

command in privileged EXEC mode.

Monitoring and Maintaining the Asynchronous Line Monitoring feature Feature

To monitor and maintain the Asynchronous Line Monitoring feature feature, use the EXEC commands included in the steps in the “Verifying Dial String Order” section.

Configuration Examples

This section provides the following configuration examples:

- Legacy Dialer with Multiple Dial Strings Example

- Dialer Profile Configuration with Multiple Dial Strings Example

Legacy Dialer with Multiple Dial Strings Example

The following example configures the dialing software to try the telephone number (dial string) of the last successful call when starting a new call, rather than the first telephone number in the list:

interface Serial0/0

ip address 10.2.1.130 255.255.255.0

encapsulation ppp

dialer in-band

dialer map ip 10.2.1.131 name jones1 modem-script test 5554004

dialer map ip 10.2.1.131 name jones1 modem-script test 5554005

dialer map ip 10.2.1.131 name jones1 modem-script test 5554006

dialer-group 1

dialer order last-successful

Dialer Profile Configuration with Multiple Dial Strings Example

The following example configures the dialing software to try the telephone number following the most recently used telephone number (dial string) when starting a new call, rather than the first telephone number in the list:

interface Dialer0

ip address 10.1.1.130 255.255.255.0

encapsulation ppp

dialer pool 1

dialer string 1904

dialer string 1905

dialer-group 1

dialer order round-robin

Command Reference

- dialer order

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007-2009 Cisco Systems, Inc. All rights reserved.

Configuring Dialer Cisco Express Forwarding

This document describes the Dialer Cisco Express Forwarding feature.

Feature History

Release

Modification

12.2(4)T

This feature was introduced.

Contents

This document includes the following sections:

- Restrictions for Dialer Cisco Express Forwarding

- Information About Dialer Cisco Express Forwarding

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Configuration Tasks

- Monitoring and Maintaining Dialer Cisco Express Forwarding Interfaces

- Configuration Examples

Restrictions for Dialer Cisco Express Forwarding

- The Dialer Cisco Express Forwarding feature is not supported when a static route points to the Dialer without specifying a next hop IP address. When using Cisco IOS Release 12.3(11)T and higher, the ppp ipcp default route command may be used in Dialer interface configuration mode to work around this restriction.

- Dialer interfaces do not support ipv6 cef switching.

Information About Dialer Cisco Express Forwarding

The Dialer Cisco Express Forwarding feature introduces Cisco Express Forwarding support for dialer interfaces. The Dialer Cisco Express Forwarding feature allows for packets to be Cisco Express Forwarding-switched across dialer interfaces rather than being low-end switched (LES) or fast-switched. Compared to fast-switching, Cisco Express Forwarding-switching support improves switching performance by decreasing CPU utilization and lowering the packet loss rate.

DDR-Dependent Implementation Decisions

You must decide whether to implement legacy dial-on-demand routing (DDR) or the newer dialer profiles.

Dialer Profiles

The dialer profiles implementation of DDR is based on a separation between logical and physical interface configuration. Dialer profiles also allow the logical and physical configurations to be bound together dynamically on a per-call basis.

Dialer profiles are advantageous when:

- you want to share an interface (ISDN, asynchronous, or synchronous serial) to place or receive calls.

- you want to change any configuration on a per-user basis.

- you want to maximize the ISDN channel usage by using the Dynamic Multiple Encapsulations feature to configure various encapsulation types and per-user configurations on the same ISDN B channel at different times according to the type of call.

- you want to bridge many destinations and avoid split horizon problems.

Most routed protocols are supported; however, International Organization for Standardization Connectionless Network Service (ISO CLNS) is not supported.

If you decide to configure dialer profiles, you must disable the validation of source addresses for the routed protocols you support.

, Release 12.2.

Legacy DDR

Legacy DDR is powerful and comprehensive, but its limitations affect scaling and extensibility. Legacy DDR is based on a static binding between the per-destination call specification and the physical interface configuration.

However, legacy DDR has many strengths. It supports Frame Relay, ISO CLNS, LAPB, snapshot routing, and all routed protocols that are supported on Cisco routers. By default, legacy DDR supports fast-switching.

, Release 12.2.

Benefits

Improved Performance

Cisco Express Forwarding is less CPU-intensive than fast-switching route caching. More CPU processing power can be dedicated to Layer 3 services such as quality of service (QoS) and encryption.

Resilience

Cisco Express Forwarding offers an unprecedented level of switching consistency and stability in large dynamic networks. In dynamic networks, fast-switched cache entries are frequently invalidated due to routing changes. These changes can cause traffic to be process-switched by using the routing table, rather than fast-switched by using the route cache. Because the Forwarding Information Base (FIB) lookup table contains all the known routes that exist in the routing table, it eliminates route cache maintenance and the fast-switch or process-switch forwarding scenario. Cisco Express Forwarding can switch traffic more efficiently than the typical demand caching schemes.

Although you can use Cisco Express Forwarding in any part of a network, it is designed for high-performance, highly resilient Layer 3 IP backbone-switching.

Related Documents

- Cisco IOS Dial Technologies Configuration Guide , Release 12.2

- Cisco IOS Dial Technologies Command Reference , Release 12.2

Supported Platforms

- Cisco 1003 router

- Cisco 1004 router

- Cisco 1005 router

- Cisco 1600 series

- Cisco 2600 series

- Cisco 3620 series

- Cisco 3640 series

- Cisco 3660 series

- Cisco 7000 series

- Cisco 7100 series

- Cisco 7200 series

- Cisco AS5300 series

- Cisco AS5400 series

- Cisco AS5800 series

Determining Platform Support Through Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Feature Navigator. Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image.

To access Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions at http://www.cisco.com/register.

Feature Navigator is updated when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Feature Navigator homepage at the following URL:

http://www.cisco.com/go/fn

Supported Standards, MIBs, and RFCs

Standards

None

MIBs

None

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

RFCs

None

Configuration Tasks

None

Monitoring and Maintaining Dialer Cisco Express Forwarding Interfaces

To monitor and maintain Dialer Cisco Express Forwarding interfaces, use the following EXEC commands:

Command

Purpose

Displays debugging information about various Cisco Express Forwarding events.

Displays Cisco Express Forwarding adjacency table information.

Displays network layer IP information about a specified interface.

Configuration Examples

None

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007-2010 Cisco Systems, Inc. All rights reserved.

CEF Support for Dialer Profiles on Cisco 7500 Routers

The CEF Support for Dialer Profiles on Cisco 7500 Routers feature adds support for Cisco Express Forwarding (CEF) switching on dialer profile interfaces, on Cisco 7500 routers with the Route Switch Processor (RSP).

Feature History for the CEF Support for Dialer Profiles on Cisco 7500 Routers Feature

Release

Modification

12.2(4)T

This feature was introduced.

12.3(4)T

Support for this feature was added for dialer profile interfaces on Cisco 7500 routers with an RSP.

Finding Support Information for Platforms and Cisco IOS Software Images

at the login dialog box and follow the instructions that appear.

Contents

- Restrictions for Asynchronous Line Monitoring feature

- Information About Asynchronous Line Monitoring feature

- How to Implement Dialer CEF Support on Cisco 7500 Routers with RSP

- Configuration Examples for Asynchronous Line Monitoring feature

- Additional References

- Command Reference

Restrictions for Asynchronous Line Monitoring feature

The Asynchronous Line Monitoring feature feature does not support distributed CEF (dCEF) switching on dialer profile interfaces.

Information About Asynchronous Line Monitoring feature

To use the Asynchronous Line Monitoring feature feature, you need to understand the following concept:

- CEF Switching Across Dialer Interfaces

CEF Switching Across Dialer Interfaces

The Asynchronous Line Monitoring feature feature introduced in Cisco IOS Release 12.3(4)T adds support for CEF switching across dialer interfaces on Cisco 7500 routers with an RSP.

CEF switching on dialer profile interfaces allows packets to be CEF switched across the interface, rather than fast switched or process switched. CEF switching avoids the overhead of continuous cache cycles by using a Forwarding Information Base (FIB) to make the destination switching decision. The FIB mirrors the contents of the IP routing table, that is, there is a one-to-one correspondence between FIB table entries and routing table prefixes and, therefore, no need to maintain a separate route cache.

This FIB provides significant benefits in terms of performance, scalability, network resilience, and functionality, particularly in large complex networks with dynamic traffic patterns. CEF switching is less CPU-intensive than fast switched route caching. More CPU processing power can be dedicated to Layer 3 services such as quality of service (QoS) and encryption.

CEF switching also offers an unprecedented level of switching consistency and stability in large dynamic networks. In dynamic networks, fast-switched cache entries are frequently invalidated due to routing changes. These changes can cause traffic to be process switched using the FIB routing table, rather than fast switched using the route cache. Because the FIB lookup table contains all known routes that exist in the routing table, it eliminates route cache maintenance and the fast-switch or process-switch forwarding scenario. CEF can switch traffic more efficiently than typical demand caching schemes.

How to Implement Dialer CEF Support on Cisco 7500 Routers with RSP

You need perform no configuration tasks to use the CEF support for dialer interfaces configured on a Cisco 7500 with the RSP; the dialer CEF switching functionality is inherent in the Cisco IOS Release 12.3(4)T software.

The Asynchronous Line Monitoring feature feature has been tested successfully with dialer interface functionality including dialer profiles, legacy dial-on-demand routing (DDR), and large-scale dial-out Multiprotocol Label Switching Virtual Private Network (MPLS VPN).

The following section provides an optional task to verify that dialer CEF is enabled:

- Verifying that Asynchronous Line Monitoring feature Feature Is Operational

Verifying that Asynchronous Line Monitoring feature Feature Is Operational

Perform the following task to verify that the Asynchronous Line Monitoring feature feature is operational.

SUMMARY STEPS

]

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

}

Router# debug ip cef dialer

Records various CEF events.

- dialer —Records IP CEF events for dialer interfaces.

Step 3

]

Router# show adjacency dialer1 internal

Displays an adjacency, if it exists, for a connected device, and whether the adjacency is valid.

- internal —Displays CEF adjacency table dialer interface information.

Step 4

]

Router# show ip interface dialer1

Displays the usability status of IP interfaces, and will display whether CEF is enabled and the CEF switching vector is set.

Step 5

Router> exit

Exits privileged EXEC mode.

Configuration Examples for Asynchronous Line Monitoring feature

This section provides the following examples for the Asynchronous Line Monitoring feature feature:

- Recording CEF Events for Dialer Interface: Example

- Displaying CEF Adjacency Table for Dialer Interface: Example

- Displaying CEF Switching Status on IP Dialer Interface: Example

Recording CEF Events for Dialer Interface: Example

command:

Router# debug ip cef dialer

00:31:44:CEF-Dialer (profile dynamic encap (not MLP)):add link to 10.10.10.2 via Dialer1 through Dialer1

00:31:44:CEF-Dialer:adjacency added:0x81164850

00:31:44:CEF-Dialer:adjacency found:0x81164850; fib->count:1

Displaying CEF Adjacency Table for Dialer Interface: Example

command for a dialer profile that indicates where adjacency for the dialer interface is updated:

Router# show adjacency dialer1 internal

Protocol Interface Address

IP Dialer1 point2point(9)

22 packets, 2288 bytes

FF030021

CEF expires:00:01:01

refresh:00:00:13

Fast adjacency disabled

IP redirect enabled

IP mtu 1500 (0x0)

Fixup disabled

Adjacency pointer 0x826B1F10, refCount 9

Connection Id 0x0

Bucket 14

Displaying CEF Switching Status on IP Dialer Interface: Example

text, for purpose of example.

Router# show ip interface dialer1

Dialer1 is up, line protocol is up

Internet address is 10.10.10.1/24

Broadcast address is 255.255.255.255

Address determined by setup command

MTU is 1500 bytes

Helper address is not set

Directed broadcast forwarding is disabled

Outgoing access list is not set

Inbound access list is not set

Proxy ARP is enabled

Security level is default

Split horizon is enabled

ICMP redirects are always sent

ICMP unreachables are always sent

ICMP mask replies are never sent

IP fast switching is enabled

IP fast switching on the same interface is enabled

IP Flow switching is disabled

IP CEF switching is enabled

IP CEF Fast switching turbo vector

IP multicast fast switching is enabled

IP multicast distributed fast switching is disabled

IP route-cache flags are Fast, CEF

Additional References

The following sections provide references related to the Asynchronous Line Monitoring feature feature.

Related Documents

Related Topic

Document Title

Cisco Express Forwarding

- Cisco IOS IP Switching Configuration Guide ; refer to the Cisco Express Forwarding chapters in “Part 1: Cisco IOS Switching Paths”

- Cisco IOS IP Switching Command Reference

Dialer interfaces and profiles; Dialer CEF

- Cisco IOS Dial Technologies Configuration Guide ; refer to the chapters “Configuring Peer-to-Peer DDR with Dialer Profiles” and “Dialer CEF”.

- Cisco IOS Dial Technologies Command Reference

Standards

Standards

Title

None

—

MIBs

MIBs

MIBs Link

None

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

RFCs

RFCs

Title

None

Technical Assistance

Description

Link

Technical Assistance Center (TAC) home page, containing 30,000 pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.

Command Reference

.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001-2009 Cisco Systems, Inc. All rights reserved.

Configuring Snapshot Routing

This chapter describes how to configure snapshot routing. It includes the following main sections:

- Snapshot Routing Overview

- How to Configure Snapshot Routing

- Monitoring and Maintaining DDR Connections and Snapshot Routing

- Configuration Examples for Snapshot Routing

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

Snapshot Routing Overview

Snapshot routing enables a single router interface to call other routers during periods when the line protocol for the interface is up (these are called “active periods”). The router dials in to all configured locations during such active periods to get routes from all the remote locations.

The router can be configured to exchange routing updates each time the line protocol goes from “down” to “up” or from “dialer spoofing” to “fully up.” The router can also be configured to dial the server router in the absence of regular traffic if the active period time expires.

Snapshot routing is useful in two command situations:

- Configuring static routes for dial-on-demand routing (DDR) interfaces

- Reducing the overhead of periodic updates sent by routing protocols to remote branch offices over a dedicated serial line

When configuring snapshot routing, you choose one router on the interface to be the client router and one or more other routers to be server routers. The client router determines the frequency at which routing information is exchanged between routers.

Routing information is exchanged during an active period. During the active period, a client router dials all the remote server routers for which it has a snapshot dialer map defined in order to get routes from all the remote locations. The server router provides information about routes to each client router that calls.

At the end of the active period, the router takes a snapshot of the entries in the routing table. These entries remain frozen during a quiet period. At the end of the quiet period, another active period starts during which routing information is again exchanged; see Figure 1.

Figure 1 Active and Quiet Periods in Snapshot Routing

When the router makes the transition from the quiet period to the active period, the line might not be available for a variety of reasons. For example, the line might be down or busy, or the permanent virtual circuit (PVC) might be down. If this happens, the router has to wait through another entire quiet period before it can update its routing table entries. This wait might be a problem if the quiet period is very long—for example, 12 hours. To avoid the need to wait through the quiet period, you can configure a retry period. If the line is not available when the quiet period ends, the router waits for the amount of time specified by the retry period and then makes the transition to an active period. See to Figure 2.

Figure 2 Retry Period in Snapshot Routing

commands in order and will use the retry time for the lines that it cannot immediately access.

The following routed protocols support snapshot routing. Note that these are all distance-vector protocols.

- AppleTalk—Routing Table Maintenance Protocol (RTMP)

- Banyan VINES—Routing Table Protocol (RTP)

- IP—Routing Information Protocol (RIP), Interior Gateway Routing Protocol (IGRP)

- Internet Protocol Exchange (IPX)—RIP, Service Advertisement Protocol (SAP)

How to Configure Snapshot Routing

To configure snapshot routing, perform the tasks in the following sections:

- Configuring the Client Router (Required)

- Configuring the Server Router (Required)

You can also monitor and maintain interfaces configured for snapshot routing. For tips on maintaining your network with snapshot routing, see the section “Monitoring and Maintaining DDR Connections and Snapshot Routing” later in this chapter.

For an example of configuring snapshot routing, see the section “Configuration Examples for Snapshot Routing” at the end of this chapter.

Configuring the Client Router

To configure snapshot routing on the client router that is connected to a dedicated serial line, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Specifies a serial interface.

Step 2

]

Configures the client router.

To configure snapshot routing on the client router that is connected to an interface configured for DDR, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Specifies a serial interface.

Step 2

Configures a dialer rotary group.

Step 3

Specifies a dialer interface.

Step 4

]

Configures the client router.

Step 5

Defines a dialer map.

Repeat these steps for each map you want to define. Maps must be provided for all the remote server routers that this client router is to call during each active period.

Because ISDN BRI and PRI automatically have rotary groups, you need not define a rotary group when configuring snapshot routing.

To configure snapshot routing on the client router over an interface configured for BRI or PRI, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Specifies a BRI interface.

Step 2

]

Configures the client router.

Step 3

Defines a dialer map.

Configuring the Server Router

To configure snapshot routing on the server router that is connected to a dedicated serial line, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Specifies a serial interface.

Step 2

]

Configures the server router.

To configure snapshot routing on the associated server router that is connected to an interface configured for DDR, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Specifies a serial interface.

Step 2

Specifies a dialer interface.

Step 3

]

Configures the server router.

The active period for the client router and its associated server routers should be the same.

Monitoring and Maintaining DDR Connections and Snapshot Routing

To monitor DDR connections and snapshot routing, use any of the following commands in privileged EXEC mode:

Command

Purpose

]

Displays general diagnostics about the DDR interface.

Displays information about the ISDN interface.

Terminates the snapshot routing quiet period on the client router within 2 minutes.

]

Displays information about snapshot routing parameters.

Clears the values of the general diagnostic statistics.

Configuration Examples for Snapshot Routing

The following example configures snapshot routing on an interface configured for DDR on the client router. In this configuration, a single client router can call multiple server routers. The client router dials to all different locations during each active period to get routes from all those remote locations.

command allows the client router to dial the server router in the absence of regular traffic if the active period time expires.

interface serial 0

dialer rotary-group 3

!

interface dialer 3

dialer in-band

snapshot client 5 360 dialer

dialer map snapshot 2 4155556734

dialer map snapshot 3 7075558990

The following example configures the server router:

interface serial 2

snapshot server 5 dialer

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007-2009 Cisco Systems, Inc. All rights reserved.

Reliable Static Routing Backup Using Object Tracking

First Published: May 10, 2001

Last Updated: November 20, 2009

PPP over Ethernet (PPPoE) or IP Security Protocol (IPsec) Virtual Private Network (VPN) tunnel goes down, allowing the initiation of a backup connection from any alternative port. The Reliable Static Routing Backup Using Object Tracking feature is compatible with both preconfigured static routes and Dynamic Host Configuration Protocol (DHCP) configurations.

Finding Feature Information

For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the “Feature Information for Reliable Static Routing Backup Using Object Tracking” section.

An account on Cisco.com is not required.

Contents

- Prerequisites for Reliable Static Routing Backup Using Object Tracking

- Restrictions for Reliable Static Routing Backup Using Object Tracking

- Information About Reliable Static Routing Backup Using Object Tracking

- How to Configure Reliable Static Routing Backup Using Object Tracking

- Configuration Examples for Reliable Static Routing Backup Using Object Tracking

- Additional References

- Feature Information for Reliable Static Routing Backup Using Object Tracking

Prerequisites for Reliable Static Routing Backup Using Object Tracking

Restrictions for Reliable Static Routing Backup Using Object Tracking

This feature is supported in all Cisco IOS software images for the Cisco 1700 series modular access routers except the Cisco IOS IP Base image.

Information About Reliable Static Routing Backup Using Object Tracking

To configure the Reliable Static Routing Backup Using Object Tracking feature, you should understand the following concepts:

- Reliable Static Routing Backup Using Object Tracking

- Cisco IOS IP SLAs

- Benefits of Reliable Static Routing Backup Using Object Tracking

Reliable Static Routing Backup Using Object Tracking

The Reliable Static Routing Backup Using Object Tracking feature introduces the ability to reliably back up PPPoE or IPsec VPN deployments by initiating a DDR connection from an alternative port if the circuit to the primary gateway is interrupted. The Reliable Static Routing Backup Using Object Tracking feature can ensure reliable backup in the case of several catastrophic events, such as Internet circuit failure or peer device failure. A typical scenario is shown in Figure 1.

Figure 1 Reliable Static Routing Backup Using Object Tracking Scenario

Traffic from the remote LAN is forwarded to the main office from the primary interface of the remote router. If the connection to the main office is lost, the status of the tracked object changes from up to down. When the state of the tracked object changes to down, the routing table entry for the primary interface is removed and the preconfigured floating static route is installed on the secondary interface. Traffic is then forwarded to the preconfigured destination from the secondary interface. If DDR is configured on the secondary interface, interesting traffic will trigger DDR. The backup circuit can be configured to use the public switched telephone network (PSTN) or the Internet. When the state of the tracked object changes from down to up, the routing table entry for the primary interface is reinstalled and the floating static route for the secondary interface is removed.

Cisco IOS IP SLAs

The Reliable Static Routing Backup Using Object Tracking feature uses Cisco IOS IP Service Level Agreements (IP SLAs), a network monitoring feature set, to generate ICMP pings to monitor the state of the connection to the primary gateway. Cisco IOS IP SLAs is configured to ping a target, such as a publicly routable IP address or a target inside the corporate network. The pings are routed from the primary interface only. A track object is created to monitor the status of the Cisco IOS IP SLAs configuration. The track object informs the client, the static route, if a state change occurs. The preconfigured floating static route on the secondary interface will be installed when the state changes from up to down.

HTTP GET, User Datagram Protocol (UDP) echo, or any other protocol supported by Cisco IOS IP SLAs can be used instead of ICMP pings.

Benefits of Reliable Static Routing Backup Using Object Tracking

PPPoE and IPsec VPN deployments provide cost-effective and secure Internet-based solutions that can replace traditional dialup and Frame Relay circuits.

The Reliable Static Routing Backup Using Object Tracking feature can determine the state of the primary connection without enabling a dynamic routing protocol.

The Reliable Static Routing Backup Using Object Tracking feature introduces a reliable backup solution for PPPoE and IPsec VPN deployments, allowing these solutions to be used for critical circuits that must not go down without a backup circuit automatically engaging.

How to Configure Reliable Static Routing Backup Using Object Tracking

This section contains the following tasks:

- Configuring the Primary Interface for Reliable Static Routing Backup Using Object Tracking (required)

- Configuring the Backup Interface for Reliable Static Routing Backup Using Object Tracking

- Configuring Network Monitoring with Cisco IOS IP SLAs for Reliable Static Routing Backup Using Object Tracking (required)

- Configuring the Routing Policy for Reliable Static Routing Backup Using Object Tracking (required)

- Configuring the Default Route for the Primary Interface Using Static Routing (required)

- Configuring a Floating Static Default Route on the Secondary Interface (required)

- Verifying the State of the Tracked Object for Reliable Static Routing Backup Using Object Tracking (optional)

Configuring the Primary Interface for Reliable Static Routing Backup Using Object Tracking

You must configure the connection between the primary interface and the remote gateway. The status of this connection will be monitored by the Reliable Static Routing Backup Using Object Tracking feature.

The primary interface can be configured in one of three ways: for PPPoE, DHCP, or static routing. You must choose one of these configuration types. If you are not sure of which method to use with your network configuration, consult your Internet service provider (ISP) or network administrator.

Perform one of the following tasks to configure the primary interface:

- Configuring the Primary Interface for PPPoE

- Configuring the Primary Interface for DHCP

- Configuring the Primary Interface for Static Routing

Configuring the Primary Interface for PPPoE

Perform this task to configure the primary interface for PPPoE.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

]

Router(config)# interface ATM 2/0

Configures an interface type and enters interface configuration mode.

Step 4

Router(config-if)# description primary-link

Adds a description to the interface configuration.

Step 5

Router(config-if)# no ip address

Removes IP addresses configured on the interface.

Step 6

pvc [ name ] vpi / vci [ ces | ilmi | qsaal | smds | l2transport ]

Router(config-if)# pvc 0/33

Creates or assigns a name to an ATM permanent virtual circuit (PVC), specifies the encapsulation type on an ATM PVC, and enters ATM virtual circuit configuration mode.

Step 7

pppoe-client dial-pool-number number [ dial-on-demand ]

Router(config-if-atm-vc)# pppoe-client dial-pool-number 1

Configures a PPPoE client and specifies DDR functionality.

Step 8

exit

Router(config-if-atm-vc)# exit

Exits ATM virtual circuit configuration mode.

Configuring the Primary Interface for DHCP

Perform this task to configure the primary interface for DHCP.

SUMMARY STEPS

]

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

]

Router(config)# interface ethernet 0/0

Configures an interface type and enters interface configuration mode.

Step 4

Router(config-if)# description primary-link

Adds a description to the interface configuration.

Step 5

Configures the DHCP client to associate any added routes with the specified track number.

- route track number —Associates a track object with the DHCP-installed static route. Valid values for the number argument range from 1 to 500.

command is issued after an IP address has been acquired from DHCP, it will not take effect until the next time the router acquires an IP address from DHCP.

Step 6

Router(config-if)# ip address dhcp

Acquires an IP address on an Ethernet interface from DHCP.

Step 7

exit

Router(config-if)# exit

Exits interface configuration mode.

Configuring the Primary Interface for Static Routing

Perform this task to configure the primary interface for static routing.

SUMMARY STEPS

]

]

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

]

Router(config)# interface FastEthernet 0/0

Configures an interface type and enters interface configuration mode.

Step 4

Router(config-if)# description primary-link

Adds a description to the interface configuration.

Step 5

]

Router(config-if)# ip address 209.165.200.225 255.0.0.0

Sets a primary or secondary IP address for an interface.

Step 6

exit

Router(config-if)# exit

Exits interface configuration mode.

Configuring the Backup Interface for Reliable Static Routing Backup Using Object Tracking

You must configure a backup interface to contact the remote gateway. If the connection between the primary interface and the remote gateway goes down, the backup interface will be used.

Perform the following task to configure the backup interface. This task applies to PPPoE, DHCP, and static routing configurations.

SUMMARY STEPS

]

]

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

]

Router(config)# interface Dialer 0

Configures an interface type and enters interface configuration mode.

Step 4

Router(config-if)# description backup-link

Adds a description to an interface configuration.

Step 5

]

Router(config-if)# ip address 209.165.201.1 255.255.255.0

Sets a secondary IP address for an interface.

Note If the connection on the primary interface goes down, the secondary interface is used as a backup interface.

Step 6

Exits interface configuration mode.

Configuring Network Monitoring with Cisco IOS IP SLAs for Reliable Static Routing Backup Using Object Tracking

The Reliable Static Routing Backup Using Object Tracking feature uses a Cisco IOS IP SLAs configuration to generate ICMP pings to monitor the state of the connection to the primary gateway.

Beginning in Cisco IOS Release 12.3(14)T, the command used to configure Cisco IOS IP SLAs was modified.

Perform one of the following tasks to configure Cisco IOS IP SLAs depending on which Cisco IOS software release you are running:

- Configuring Cisco IOS IP SLAs for Cisco IOS Release 12.3(8)T, 12.3(11)T, 12.2(33)SRA, and 12.2(33)SRE

- Configuring Cisco IOS IP SLAs for Cisco IOS Release 12.3(14)T, 12.4, 12.4(2)T, and 12.2(33)SXH

- Configuring Cisco IOS IP SLAs for Cisco IOS Release 12.4(4)T, 15.(0)1M, and Later Releases

Configuring Cisco IOS IP SLAs for Cisco IOS Release 12.3(8)T, 12.3(11)T, 12.2(33)SRA, and 12.2(33)SRE

Perform this task to create Cisco IOS IP SLAs depending on which Cisco IOS software release you are running. This task applies to PPPoE, DHCP, and static routing configurations.

SUMMARY STEPS

}]

]

}

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

]

Router(config)# rtr 1

Begins configuration for a Cisco IOS IP SLAs operation and enters RTR configuration mode.

Step 4

type echo protocol ipIcmpEcho { destination-ip-address | destination-hostname } [ source-ipaddr { ip-address | hostname }]

Router(config-rtr)# type echo protocol ipIcmpEcho 172.16.23.7

Configures a Cisco IOS IP SLAs end-to-end echo response time probe operation.

Step 5

Router(config-rtr)# timeout 1000

Sets the amount of time for which the Cisco IOS IP SLAs operation waits for a response from its request packet.

Step 6

Router(config-rtr)# frequency 3

Sets the rate at which a specified Cisco IOS IP SLAs operation is sent into the network.

Step 7

Router(config-rtr)# threshold 2

Sets the rising threshold (hysteresis) that generates a reaction event and stores history information for the Cisco IOS IP SLAs operation.

Step 8

Router(config-rtr)# exit

Exits RTR configuration mode.

Step 9

]

Router(config)# rtr schedule 1 life forever start-time now

Configures a Cisco IOS IP SLAs ICMP echo operation.

Step 10

}

Router(config)# track 123 rtr 1 reachability

Tracks the state of a Cisco IOS IP SLAs operation and enters tracking configuration mode.

Step 11

Router(config-track-list)# end

Exits tracking configuration mode.

Configuring Cisco IOS IP SLAs for Cisco IOS Release 12.3(14)T, 12.4, 12.4(2)T, and 12.2(33)SXH

Perform this task to create an Cisco IP SLAs configuration to ping the target address depending on which Cisco IOS software release you are running. This task applies to PPPoE, DHCP, and static routing configurations.

SUMMARY STEPS

]

]

}

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

]

Router(config)# ip sla monitor 1

Begins configuring a Cisco IOS IP SLAs operation and enters IP SLA monitor configuration mode.

Step 4

type echo protocol ipIcmpEcho { destination-ip-address | destination-hostname } [ source-ipaddr { ip-address | hostname } | source-interface interface-name ]

Router(config-sla-monitor)# type echo protocol ipIcmpEcho 172.16.23.7

Configures a Cisco IOS IP SLAs end-to-end ICMP echo response time operation and enters IP SLAs ICMP echo configuration mode.

Step 5

Router(config-sla-monitor-echo)# timeout 1000

Sets the amount of time for which the Cisco IOS IP SLAs operation waits for a response from its request packet.

Step 6

Router(config-sla-monitor-echo)# frequency 3

Sets the rate at which a specified Cisco IOS IP SLAs operation is sent into the network.

Step 7

Router(config-sla-monitor-echo)# threshold 2

Sets the rising threshold (hysteresis) that generates a reaction event and stores history information for the Cisco IOS IP SLAs operation.

Step 8

Router(config-sla-monitor-echo)# exit

Exits IP SLAs ICMP echo configuration mode.

Step 9

] [recurring]

Router(config)# ip sla monitor schedule 1 life forever start-time now

Configures the scheduling parameters for a single Cisco IOS IP SLAs operation.

Step 10

}

Router(config)# track 123 rtr 1 reachability

Tracks the state of a Cisco IOS IP SLAs operation and enters tracking configuration mode.

Step 11

Router(config-track-list)# end

Exits tracking configuration mode.

Configuring Cisco IOS IP SLAs for Cisco IOS Release 12.4(4)T, 15.(0)1M, and Later Releases

Perform this task to create Cisco IP SLAs configuration in Cisco IOS Release 12.4(4)T, 15.0(1)M, and later releases to ping the target address. This task applies to PPPoE, DHCP, and static routing configurations.

SUMMARY STEPS

]

]

}

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

]

Router(config)# ip sla 1

Begins configuring a Cisco IOS IP SLAs operation and enters IP SLA configuration mode.

Step 4

icmp-echo { destination-ip-address | destination-hostname } [ source-ip { ip-address | hostname } | source-interface interface-name ]

Router(config-ip-sla)# icmp-echo 172.16.23.7

Configures a Cisco IOS IP SLAs end-to-end ICMP echo response time operation and enters IP SLAs ICMP echo configuration mode.

Step 5

Router(config-ip-sla-echo)# timeout 1000

Sets the amount of time for which the Cisco IOS IP SLAs operation waits for a response from its request packet.

Step 6

Router(config-ip-sla-echo)# frequency 3

Sets the rate at which a specified Cisco IOS IP SLAs operation is sent into the network.

Step 7

Router(config-ip-sla-echo)# threshold 2

Sets the rising threshold (hysteresis) that generates a reaction event and stores history information for the Cisco IOS IP SLAs operation.

Step 8

Router(config-ip-sla-echo)# exit

Exits IP SLAs ICMP echo configuration mode.

Step 9

] [recurring]

Router(config-ip-sla-echo)# ip sla schedule 1 life forever start-time now

Configures the scheduling parameters for a single Cisco IOS IP SLAs operation.

Step 10

}

Router(config)# track 123 rtr 1 reachability

Tracks the state of a Cisco IOS IP SLAs operation and enters tracking configuration mode.

Step 11

Router(config-track-list)# end

Exits tracking configuration mode.

Configuring the Routing Policy for Reliable Static Routing Backup Using Object Tracking

In order to track the status of the primary connection to the remote gateway, the Cisco IOS IP SLAs ICMP pings must be routed only from the primary interface.

Perform one of the following tasks to configure a routing policy that will ensure that the Cisco IOS IP SLAs pings are always routed out of the primary interface:

- Configuring a Routing Policy for PPPoE

- Configuring a Routing Policy for DHCP

- Configuring a Routing Policy for Static Routing

Configuring a Routing Policy for PPPoE

Perform this task to configure a routing policy if the primary interface is configured for PPPoE.

SUMMARY STEPS

]

]

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

]

Router(config)# access-list 101 permit icmp any host 172.16.23.7 echo

Defines an extended IP access list.

Step 4

]

Router(config)# route-map MY-LOCAL-POLICY permit 10

Enters route-map configuration mode and defines the conditions for redistributing routes from one routing protocol into another.

Step 5

]

Router(config-route-map)# match ip address 101

Distributes any routes that have a destination network number address that is permitted by a standard or extended access list, or performs policy routing on packets.

Step 6

]

Router(config-route-map)# set interface null 0

Indicates where to output packets that pass a match clause of a route map for policy routing.
in this scenario. If the next hop is not set because the interface is down, the packet is routed to the null interface and discarded. Otherwise policy routing fails and the packet is routed using the Routing Information Base (RIB) card. Routing the packet using the RIB card is undesirable.

Step 7

Router(config-route-map)# exit

Exits route-map configuration mode.

Step 8

Router(config)# ip local policy route-map MY-LOCAL-POLICY

Identifies a route map to use for local policy routing.

Step 9

Router(config)# end

Exits global configuration mode.

Configuring a Routing Policy for DHCP

Perform this task to ensure that the primary interface is configured for DHCP:

SUMMARY STEPS

]

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

]

Router(config)# access-list 101 permit icmp any host 172.16.23.7 echo

Defines an extended IP access list.

Step 4

]

Router(config)# route-map MY-LOCAL-POLICY permit 10

Enters route-map configuration mode and defines the conditions for redistributing routes from one routing protocol into another.

Step 5

]

Router(config-route-map)# match ip address 101

Distributes any routes that have a destination network number address that is permitted by a standard or extended access list, or performs policy routing on packets.

Step 6

Router(config-route-map)# set ip next-hop dynamic dhcp

Sets the next hop to the gateway that was most recently learned by the DHCP client.

Step 7

Router(config-route-map)# exit

Exits route-map configuration mode.

Step 8

Router(config)# ip local policy route-map MY-LOCAL-POLICY

Identifies a route map to use for local policy routing.

Step 9

Router(config)# end

Exits global configuration mode.

Configuring a Routing Policy for Static Routing

Perform one of the following tasks if the primary interface is configured for static routing:

- Configuring a Routing Policy for Static Routing with a Point-to-Point Primary Gateway

- Configuring a Routing Policy for Static Routing with a Multipoint Primary Gateway

Configuring a Routing Policy for Static Routing with a Point-to-Point Primary Gateway

Perform this task to configure a routing policy if the primary interface is configured for static routing and the primary gateway is a point-to-point gateway.

SUMMARY STEPS

]

]

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

]

Router(config)# access-list 101 permit icmp any host 172.16.23.7 echo

Defines an extended IP access list.

Step 4

]

Router(config)# route-map MY-LOCAL-POLICY permit 10

Enters route-map configuration mode and defines the conditions for redistributing routes from one routing protocol into another.

Step 5

]

Router(config-route-map)# match ip address 101

Distributes any routes that have a destination network number address that is permitted by a standard or extended access list, or performs policy routing on packets.

Step 6

]

Router(config-route-map)# set interface dialer 0 Null 0

Indicates where to output packets that pass a match clause of a route map for policy routing.

Step 7

Router(config-route-map)# exit

Exits route-map configuration mode.

Step 8

Router(config)# ip local policy route-map MY-LOCAL-POLICY

Identifies a route map to use for local policy routing.

Step 9

Router(config)# end

Exits global configuration mode.

Configuring a Routing Policy for Static Routing with a Multipoint Primary Gateway

Perform this task to configure a routing policy if the primary interface is configured for static routing and the primary gateway is a multipoint gateway.

SUMMARY STEPS

]

]

]

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

]

Router(config)# access-list 101 permit icmp any host 172.16.23.7 echo

Defines an extended IP access list.

Step 4

]

Router(config)# route-map MY-LOCAL-POLICY permit 10

Enters route-map configuration mode and defines the conditions for redistributing routes from one routing protocol into another.

Step 5

]

Router(config-route-map)# match ip address 101

Distributes any routes that have a destination network number address that is permitted by a standard or extended access list, or performs policy routing on packets.

Step 6

]

Router(config-route-map)# set ip next-hop 10.1.1.242

Indicates where to output packets that pass a match clause of a route map for policy routing.

Step 7

]

Router(config-route-map)# set interface null 0

Indicates where to output packets that pass a match clause of a route map for policy routing.

Step 8

Router(config-route-map)# exit

Exits route-map configuration mode.

Step 9

Router(config)# ip local policy route-map MY-LOCAL-POLICY

Identifies a route map to use for local policy routing.

Step 10

Router(config)# end

Exits global configuration mode.

Configuring the Default Route for the Primary Interface Using Static Routing

Perform this task to configure the static default route only if you are using static routing.

SUMMARY STEPS

]

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# ip route 0.0.0.0 0.0.0.0 10.1.1.242 track 123

Establishes static routes.

- track number —Specifies that the static route will be installed only if the configured track object is up.

Step 4

Router(config)# end

Exits global configuration mode.

Configuring a Floating Static Default Route on the Secondary Interface

Perform this task to configure a floating static default route on the secondary interface. This task applies to PPPoE, DHCP, and static routing configurations.

SUMMARY STEPS

]

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

]

Router(config)# ip route 0.0.0.0 0.0.0.0 10.2.2.125 254

Establishes static routes and defines the next hop.

Verifying the State of the Tracked Object for Reliable Static Routing Backup Using Object Tracking

Perform the following task to determine if the state of the tracked object is up or down.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# show ip route track-table

Displays information about the IP route track table.

Configuration Examples for Reliable Static Routing Backup Using Object Tracking

This section provides the following configuration examples:

- Configuring Reliable Static Routing Backup Using Object Tracking Using PPPoE: Example

- Configuring Reliable Static Routing Backup Using Object Tracking Using DHCP: Example

- Configuring Reliable Static Routing Backup Using Object Tracking: Example

- Verifying the State of the Tracked Object: Example

Configuring Reliable Static Routing Backup Using Object Tracking Using PPPoE: Example

The following example shows how to configure the Reliable Static Routing Backup Using Object Tracking feature using PPPoE. The primary interface is an ATM interface, and the backup interface is a BRI interface. This example applies to Cisco IOS Release 12.3(8)T, 12.3(11)T, 12.2(33)SRA, 12.2(33)SXH, and 12.2(33)SRE.

interface ATM 0

description primary-link

no ip address

pvc 0/33

pppoe-client dial-pool-number 1

!

interface BRI 0

description backup-link

ip address 10.2.2.2 255.0.0.0

!

rtr 1

type echo protocol ipIcmpEcho 172.16.23.7

timeout 1000

frequency 3

threshold 2

rtr schedule 1 life forever start-time now

track 123 rtr 1 reachability

access list 101 permit icmp any host 172.16.23.7 echo

route map MY-LOCAL-POLICY permit 10

match ip address 101

set interface null 0

!

ip local policy route-map MY-LOCAL-POLICY

ip route 0.0.0.0 0.0.0.0 10.2.2.125 254

Configuring Reliable Static Routing Backup Using Object Tracking Using DHCP: Example

The following example show how to configure the Reliable Static Routing Backup Using Object Tracking feature using DHCP. The primary interface is an Ethernet interface, and the backup interface is a serial interface. This example applies to Cisco IOS Release 12.3(14)T.

!

ip dhcp-client default-router distance 25

ip sla monitor 1

type echo protocol ipIcmpEcho 172.16.23.7

timeout 1000

threshold 2

frequency 3

ip sla monitor schedule 1 life forever start-time now

track 123 rtr 1 reachability

!

interface Ethernet0/0

description primary-link

ip dhcp client route track 123

ip address dhcp

!

interface Serial2/0

description backup-link

ip address 209.165.202.129 255.255.255.255

!

ip local policy route-map MY-LOCAL-POLICY

ip route 0.0.0.0 0.0.0.0 10.2.2.125 254

!

access-list 101 permit icmp any host 172.16.23.7 echo

route-map MY-LOCAL-POLICY permit 10

match ip address 101

set ip next-hop dynamic dhcp

Configuring Reliable Static Routing Backup Using Object Tracking: Example

The following example shows how to configure the Reliable Static Routing Backup Using Object Tracking feature using static routing for a point-to-point primary gateway. The primary interface is a PPPoE Fast Ethernet interface, and the backup interface is a dialer interface. This example applies to Cisco IOS Release 12.3(14)T and later releases.

interface FastEthernet 0/0

description primary-link

ip address 209.165.202.129 255.255.255.255

interface Dialer 0

description backup-link

ip address 209.165.200.225 255.255.255.255

ip sla monitor 1

type echo protocol ipIcmpEcho 172.16.23.7

timeout 1000

frequency 3

threshold 2

ip sla monitor schedule 1 life forever start-time now

track 123 rtr 1 reachability

access list 101 permit icmp any host 172.16.23.7 echo

route map MY-LOCAL-POLICY permit 10

match ip address 101

set interface dialer 0 null 0

!

ip local policy route-map MY-LOCAL-POLICY

ip route 0.0.0.0 0.0.0.0 10.1.1.242 track 123

ip route 0.0.0.0 0.0.0.0 10.2.2.125 254

The following example configures the Reliable Static Routing Backup Using Object Tracking feature using static routing for a multipoint primary gateway. Both the primary interface and the backup interface are Ethernet interfaces. This example applies to Cisco IOS Release 12.3(14)T and later releases.

interface ethernet 0

description primary-link

ip address 209.165.202.129 255.255.255.255

interface ethernet 1

description backup-link

ip address 209.165.200.225 255.255.255.255

ip sla monitor 1

type echo protocol ipIcmpEcho 172.16.23.7

timeout 1000

frequency 3

threshold 2

ip sla monitor schedule 1 life forever start-time now

track 123 rtr 1 reachability

access list 101 permit icmp any host 172.16.23.7 echo

route map MY-LOCAL-POLICY permit 10

match ip address 101

set ip next-hop 10.1.1.242

set interface null 0

!

ip local policy route-map MY-LOCAL-POLICY

ip route 0.0.0.0 0.0.0.0 10.1.1.242 track 123

ip route 0.0.0.0 0.0.0.0 10.2.2.125 254

Verifying the State of the Tracked Object: Example

The following example displays information about track objects in the IP route track table:

Router# show ip route track-table

ip route 0.0.0.0 0.0.0.0 10.1.1.242 track-object 123 state is [up]

Additional References

The following sections provide references related to the Reliable Static Routing Backup Using Object Tracking feature.

Related Documents

Related Topic

Document Title

IPsec configuration tasks

IPsec commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

VPDN configuration tasks

VPDN commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

ATM virtual circuit bundles

PPPoE commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Dial access specialized features

DDR commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

IP SLAs configuration tasks

IP SLAs commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Standards

Standards

Title

None

—

MIBs

MIBs

MIBs Link

None

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

RFCs

RFCs

Title

None

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

Feature Information for Reliable Static Routing Backup Using Object Tracking

lists the features in this module and provides links to specific configuration information. Only features that were introduced or modified in Cisco IOS Release 12.2(33)SX or Cisco IOS Releases 12.2(33)SRE or 15.0(1)M or a later release appear in this table.

Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.

. An account on Cisco.com is not required.

Table 1 Feature Information for Reliable Static Routing Backup Using Object Tracking

Feature Name

Releases

Feature Information

Reliable Static Routing Backup Using Object Tracking

15.0(1)M

The Reliable Static Routing Backup Using Object Tracking feature introduces the ability for the Cisco IOS software to use ICMP pings to identify when a PPPoE or IPsec VPN tunnel goes down, allowing the initiation of a backup connection from any alternative port. The Reliable Static Routing Backup Using Object Tracking feature is compatible with both preconfigured static routes and DHCP configurations. The following sections provide information about this feature:

- Information About Reliable Static Routing Backup Using Object Tracking

- How to Configure Reliable Static Routing Backup Using Object Tracking

.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001—2009 Cisco Systems, Inc. All rights reserved.

Configuring Dial Backup for Serial Lines

This chapter describes how to configure the primary interface to use the dial backup interface. It includes the following main sections:

- Backup Serial Interface Overview

- How to Configure Dial Backup

- Configuration Examples for Dial Backup for Serial Interfaces

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

Backup Serial Interface Overview

For a backup serial interface, an external DCE device, such as a modem attached to a circuit-switched service, must be connected to the backup serial interface. The external device must be capable of responding to a data terminal ready (DTR) Active signal by automatically dialing the preconfigured telephone number of the remote site.

A backup interface is an interface that stays idle until certain circumstances occur; then it is activated. A backup interface for a serial interface can be an ISDN interface or a different serial interface. A backup interface can be configured to be activated when any of the following three circumstances occurs:

- The primary line goes down.

- The load on the primary line reaches a certain threshold.

- The load on the primary line exceeds a specified threshold.

interface) might be configured for DDR or for Frame Relay or X.25 over a leased line, but the backup tasks are the same in all three cases.

Note Dial backup is also available using the Dialer Watch feature. Dialer Watch is based on routing characteristics instead of relying exclusively on interesting traffic conditions. For information about Dialer Watch, see the chapter “Configuring Dial Backup Using Dialer Watch” in this publication.

To configure a backup interface for a serial interface based on one of the conditions listed, complete the following general steps:

- Specify the interface and configure it as needed (for DDR, Frame Relay, or X.25). You can also specify and configure a Frame Relay subinterface.

. In this publication, see the chapter “Configuring Synchronous Serial Ports” and related chapters in the “Dial-on-Demand Routing” part for details.

- Configure the primary interface or subinterface by specifying the dial backup interface and the conditions for activating the backup interface, as described in this chapter.

- Configure the backup interface for DDR, as described in the “Dial-on-Demand Routing” part of this publication.

See the chapters “Configuring Legacy DDR Spokes” (for point-to-point legacy DDR connections) or “Configuring Legacy DDR Hubs” (for point-to-multipoint legacy DDR connections) in this publication. If you have configured dialer profiles instead of legacy DDR, see the chapter “Configuring Dial Backup with Dialer Profiles” in this publication for backup information.

How to Configure Dial Backup

You must decide whether to activate the backup interface when the primary line goes down, when the traffic load on the primary line exceeds the defined threshold, or both. The tasks you perform depend on your decision. Perform the tasks in the following sections to configure dial backup:

- Specifying the Backup Interface (Optional)

- Defining the Traffic Load Threshold (Optional)

- Defining Backup Line Delays (Optional)

Then configure the backup interface for DDR, so that calls are placed as needed. See the chapters in the “Dial-on-Demand Routing” part of this publication for more information.

For simple configuration examples, see the section “Configuration Examples for Dial Backup for Serial Interfaces” at the end of this chapter.

Specifying the Backup Interface

To specify a backup interface for a primary serial interface or subinterface, use one the following commands in interface configuration mode:

Command

Purpose

or

Cisco 7500 series routers:

or

Cisco 7200 series routers:

Selects a backup interface.

Note When you enter the backup interface command, the configured physical or logical interface will be forced to standby mode. When you use a BRI for a dial backup (with Legacy DDR), neither of the B channels can be used because the physical BRI interface is in standby mode. However, with dialer profiles, only the logical dialer interface is placed in standby mode and the physical interface (BRI) still can be used for other connections by making it a member of another pool.

When configured for legacy DDR, the backup interface can back up only one interface. For examples of selecting a backup line, see the sections “Dial Backup Using an Asynchronous Interface Example” and “Dial Backup Using DDR and ISDN Example” later in this chapter.

Defining the Traffic Load Threshold

You can configure dial backup to activate the secondary line based on the traffic load on the primary line. The software monitors the traffic load and computes a 5-minute moving average. If this average exceeds the value you set for the line, the secondary line is activated and, depending upon how the line is configured, some or all of the traffic will flow onto the secondary dialup line.

To define how much traffic should be handled at one time on an interface, use the following command in interface configuration mode:

Command

Purpose

}

Defines the traffic load threshold as a percentage of the available bandwidth of the primary line.

Defining Backup Line Delays

You can configure a value that defines how much time should elapse before a secondary line status changes after a primary line status has changed. You can define two delays:

- A delay that applies after the primary line goes down but before the secondary line is activated

- A delay that applies after the primary line comes up but before the secondary line is deactivated

To define these delays, use the following command in interface configuration mode:

Command

Purpose

}

Defines backup line delays.

For examples of how to define backup line delays, see the sections “Dial Backup Using an Asynchronous Interface Example” and “Dial Backup Using DDR and ISDN Example” at the end of this chapter.

Configuration Examples for Dial Backup for Serial Interfaces

The following sections present examples of specifying the backup interface:

- Dial Backup Using an Asynchronous Interface Example

- Dial Backup Using DDR and ISDN Example

The following sections present examples of backup interfaces configured to be activated in three different circumstances:

- The load on the primary line reaches a certain threshold.

- The load on the primary line exceeds a specified threshold.

- The primary line goes down.

Dial Backup Using an Asynchronous Interface Example

The following is an example for dial backup using asynchronous interface 1, which is configured for DDR:

interface serial 0

ip address 172.30.3.4 255.255.255.0

backup interface async1

backup delay 10 10

!

interface async 1

ip address 172.30.3.5 255.255.255.0

dialer in-band

dialer string 5551212

dialer-group 1

async dynamic routing

dialer-list 1 protocol ip permit

chat-script sillyman "" “atdt 5551212” TIMEOUT 60 “CONNECT”

line 1

modem chat-script sillyman

modem inout

speed 9600

Dial Backup Using DDR and ISDN Example

The following example shows how to use an ISDN interface to back up a serial interface.

Note When you use a BRI interface for dial backup, neither of the B channels can be used while the interface is in standby mode.

Interface BRI 0 is configured to make outgoing calls to one number. This is a legacy DDR spoke example.

interface serial 1

backup delay 0 0

backup interface bri 0

ip address 10.2.3.4 255.255.255.0

!

interface bri 0

ip address 10.2.3.5 255.255.255.0

dialer string 5551212

dialer-group 1

!

dialer-list 1 protocol ip permit

Note Dialing will occur only after a packet is received to be output on BRI 0. We recommend using the dialer-list command with the protocol and permit keywords specified to control access for dial backup. Using this form of access control specifies that all packets are interesting.

Dial Backup Service When the Primary Line Reaches Threshold Example

The following example configures the secondary line (serial 1) to be activated only when the load of the primary line reaches a certain threshold:

interface serial 0

backup interface serial 1

backup load 75 5

The secondary line will be activated when the load on the primary line is greater than 75 percent of the bandwidth of the primary line. The secondary line will then be brought down when the aggregate load between the primary and secondary lines fits within 5 percent of the primary bandwidth.

The same example on a Cisco 7500 series router would be as follows:

interface serial 1/1

backup interface serial 2/2

backup load 75 5

Dial Backup Service When the Primary Line Exceeds Threshold Example

The following example configures the secondary line (serial 1) to activate when the traffic threshold on the primary line exceeds 25 percent:

interface serial 0

backup interface serial 1

backup load 25 5

backup delay 10 60

When the aggregate load of the primary and the secondary lines returns to within 5 percent of the primary bandwidth, the secondary line is deactivated. The secondary line waits 10 seconds after the primary goes down before activating and remains active for 60 seconds after the primary returns and becomes active again.

The same example on a Cisco 7500 series router would be as follows:

interface serial 1/0

backup interface serial 2/0

backup load 25 5

backup delay 10 60

Dial Backup Service When the Primary Line Goes Down Example

The following example configures the secondary line (serial 1) as a backup line that becomes active only when the primary line (serial 0) goes down. The backup line will not be activated because of load on the primary line.

interface serial 0

backup interface serial 1

backup delay 30 60

The backup line is configured to activate 30 seconds after the primary line goes down and to remain on for 60 seconds after the primary line is reactivated.

The same example on a Cisco 7500 series router would be as follows:

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001–2009 Cisco Systems, Inc. All rights reserved.

Configuring Dial Backup Using Dialer Watch

First Published: February 24, 1998

Last Updated: February 18, 2010

The Dialer Watch feature provides enhancements to the Hot Standby Router Protocol (HSRP) function. This feature provides the backup router and backup links as soon as the primary routers and links become inactive.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the “Feature Information for Configuring Dial Backup Using Dialer Watch” section.

An account on Cisco.com is not required.

Contents

- Prerequisites for Configuring Dial Backup Using Dialer Watch

- Information About Configuring Dial Backup Using Dialer Watch

- How to Configure Dialer Backup Using Dialer Watch

- Configuration Examples for Dialer Watch

- Additional References

- Feature Information for Configuring Dial Backup Using Dialer Watch

Prerequisites for Configuring Dial Backup Using Dialer Watch

- Decide which interfaces on which routers will act as primary and secondary interfaces. Unlike traditional backup methods, you can define multiple interfaces on multiple routers instead of a singly defined interface on one router.

- Determine which addresses and networks are to be monitored or watched. Typically, this will be the address of an interface on a remote router or a network advertised by a central or remote router.

Information About Configuring Dial Backup Using Dialer Watch

To configure dial backup using the Dialer Watch feature, you should understand the following concept:

- Dialer Watch Overview

Dialer Watch Overview

Dialer Watch is a backup feature that integrates dial backup with routing capabilities. Prior dial backup implementations used the following conditions to trigger backup:

- Interesting packets were defined at central and remote routers using dial-on-demand routing (DDR).

- Connection loss occurred on a primary interface using a back up interface with floating static routes.

- Traffic thresholds were exceeded using a dialer load threshold.

Prior backup implementations may not have supplied optimum performance on some networks, such as those using Frame Relay multipoint subinterfaces or Frame Relay connections that do not support end-to-end permanent virtual circuit (PVC) status updates.

Dialer Watch provides reliable connectivity without relying solely on defining interesting traffic to trigger outgoing calls at the central router. Dialer Watch uses the convergence times and characteristics of dynamic routing protocols. Integrating backup and routing features enables Dialer Watch to monitor every deleted route. By configuring a set of watched routes that define the primary interface, you are able to monitor and track the status of the primary interface as watched routes are added and deleted. Monitoring the watched routes is done in the following sequence:

1. Whenever a watched route is deleted, Dialer Watch checks whether there is at least one valid route for any of the defined watched IP addresses.

2. If no valid route exists, the primary line is considered down and unusable.

3. If a valid route exists for at least one of the defined IP addresses and if the route is pointing to an interface other than the backup interface configured for Dialer Watch, the primary link is considered up.

4. If the primary link goes down, Dialer Watch is immediately notified by the routing protocol and the secondary link is brought up.

5. Once the secondary link is up, at the expiration of each idle timeout, the primary link is rechecked.

6. If the primary link remains down, the idle timer is indefinitely reset.

7. If the primary link is up, the secondary backup link is disconnected. Additionally, you can set a disable timer to create a delay for the secondary link to disconnect, after the primary link is reestablished.

Dialer Watch provides the following advantages:

- Routing—Backup initialization is linked to the dynamic routing protocol, rather than a specific interface or static route entry. Therefore, both primary and backup interfaces can be any interface type, and can be used across multiple interfaces and multiple routers. Dialer Watch also relies on convergence, which is sometimes preferred over traditional DDR links.

- Routing protocol independent—Static routes or dynamic routing protocols, such as Interior Gateway Routing Protocol (IGRP), Enhanced IGRP (EIGRP) or Open Shortest Path First (OSPF) can be used.

- Nonpacket semantics—Dialer Watch does not exclusively rely on interesting packets to trigger dialing. The link is automatically brought up when the primary line goes down without postponing dialing.

- Dial backup reliability—DDR redial functionality is extended to dial indefinitely in the event that secondary backup lines are not initiated. Typically, DDR redial attempts are affected by enable-timeouts and wait-for-carrier time values. Intermittent media difficulties or flapping interfaces can cause problems for traditional DDR links. However, Dialer Watch automatically reestablishes the secondary backup line on ISDN, synchronous, and asynchronous serial links.

The following prerequisites apply to Dialer Watch:

- The router is dial backup capable, meaning the router has a data communications equipment (DCE), terminal adapter, or network termination 1 device attached that supports V.25 bis .

- The router is configured for DDR. This configuration includes traditional commands such as dialer map and dialer in-band commands, and so on.

- Dialer Watch is only supported for IP at this time.

For information on how to configure traditional DDR for dial backup, see the other chapters in the “Dial Backup” part of this publication.

Note The Multilink PPP Minimum Links Mandatory feature has priority over the Dialer Watch feature. If both features are configured simultaneously then the ISDN link will not become inactive even if the primary link is active.

How to Configure Dialer Backup Using Dialer Watch

This section contains the following sections:

- Configuring the Interface to Perform DDR Backup (Required)

- Creating a Dialer List (Required)

- Setting the Disable Timer on the Backup Interface (Optional)

Configuring the Interface to Perform DDR Backup

Perform this task to configure the interface to perform DDR backup. This task initiates Dialer Watch.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# interface bri0

Enters interface configuration mode.

Step 4

Router(config)# dialer watch-group 1

Enables Dialer Watch on the backup interface.

Creating a Dialer List

Perform this task to create a dialer list. This task defines the IP addresses that you want to be watched.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# dialer watch-list 1 ip 192.0.2.0 255.255.255.224

Defines all IP addresses to be watched.

- The d ialer watch-list command is the means to detect if the primary interface is up or down. The primary interface is determined to be up when there is an available route with a valid metric to any of the addresses defined in this list, and it points to an interface other than the interface on which the dialer watch-group command is defined. The primary interface is determined to be down when there is no available route to any of the addresses defined in the dialer watch-list command.

Setting the Disable Timer on the Backup Interface

Perform this task to set the disable timer on the backup interface. You may want to implement a delay before the backup interface is dropped once the primary interface recovers. This delay can ensure stability, especially for flapping interfaces or interfaces experiencing frequent route changes.

Note The dialer watch-disable command used in Dialer Watch configurations was replaced in Cisco IOS Release 12.3(11)T by the dialer watch-list delay command. When using the dialer watch-list delay command in software later than Cisco IOS Release 12.3(11)T, you can specify both a connect and disconnect timer for the disable timer. The disconnect time specifies that the disconnect timer is started when the secondary link is up and after the idle timeout period has expired, and only when software has determined that the primary route has come up.

In Cisco IOS Releases Prior to 12.3(11)T

Perform this task to apply a disable timer.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# interface ethernet 1/0

Enters interface configuration mode.

Step 4

Router(config-if)# dialer watch-disable seconds

Applies a disable timer to the interface.

In Cisco IOS Release 12.3(11)T and Later

Perform this task to apply a disable timer.

SUMMARY STEPS

}

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# interface ethernet 1/0

Enters interface configuration mode.

Step 4

}

Router(config-if)# dialer watch-list 1 delay connect 50

Configures a disable time.

- group-number —Group number assigned to the list. Valid group numbers are from 1 to 255.

- delay —Specifies that the router will delay dialing the secondary link when the primary link becomes unavailable.

- connect connect-time —Time, in seconds, after which the router rechecks for availability of the primary link. If the primary link is still unavailable, the secondary link is then dialed. Valid times range from 1 to 2147483 seconds.

- disconnect disconnect-time —Time, in seconds, that specifies when to disconnect. Disconnect occurs when the secondary link is up and after the idle timeout period has expired, and only when software has determined that the primary route has come up. Valid times range from 1 to 2147483 seconds.

Configuration Examples for Dialer Watch

command was replaced.

- Configuring Dialer Watch Prior to Cisco IOS Release 12.3(11)T: Example

- Configuring Dialer Watch with Cisco IOS Release 12.3(11)T and Later Releases: Example

Configuring Dialer Watch Prior to Cisco IOS Release 12.3(11)T: Example

In the following example, an ISDN BRI line is used to back up a serial leased line connection by configuring the Dialer Watch feature on a router named maui-soho-01. The Dialer Watch feature enables the router to monitor the existence of a specified route. If that route is not present, the backup interface is activated. Unlike other backup methods, the Dialer Watch feature does not require interesting traffic to activate the backup interface. The configuration shown in Figure 1 uses legacy dial-on-demand routing (DDR) and the Open Shortest Path First (OSPF) routing protocol. Dialer profiles can be used in place of DDR. Once the backup connection is activated, you must ensure that the routing table is updated to use the new backup route. Additional information about the Dialer Watch feature is available at the following website:

http://www.cisco.com/warp/public/129/bri-backup-map-watch.html

For additional information on configuring legacy DDR, dialer profiles, PPP, and traditional dial backup features, see the relevant chapters in this publication.

Figure 1 Dialer Watch for Frame Relay Interfaces

Note The following example uses commands supported in Cisco IOS software prior to Release 12.3(11)T. See the updated example for configuring Dialer Watch after Cisco IOS Release 12.3(11)T that follows this example.

Configuration for maui-soho-01

maui-soho-01# show running-config

Building configuration...

Current configuration : 1546 bytes

!

version 12.1

no service single-slot-reload-enable

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname maui-soho-01

!

logging rate-limit console 10 except errors

aaa new-model

aaa authentication login default local

aaa authentication login NO_AUTHEN none

aaa authentication ppp default local

!This is basic AAA configuration for PPP calls.

enable secret 5 <deleted>

!

username maui-nas-05 password 0 cisco

!Username for remote router (maui-nas-05) and shared secret.

!Shared secret(used for CHAP authentication) must be the same on both sides.

ip subnet-zero

no ip finger

!

isdn switch-type basic-ni

!

interface Loopback0

ip address 209.165.200.225 255.255.255.224

!

interface Ethernet0

ip address 209.165.200.226 255.255.255.224

!

interface Serial0

!Primary link.

ip address 209.165.200.227 255.255.255.224

encapsulation ppp

ppp authentication chap

!

interface BRI0

ip address 209.165.200.228 255.255.255.224

!IP address for the BRI interface (backup link).

encapsulation ppp

dialer idle-timeout 30

!Idle timeout(in seconds)for this backup link.

!Dialer watch checks the status of the primary link every time the

!idle-timeout expires.

dialer watch-disable 15

!Delays disconnecting the backup interface for 15 seconds after the

!primary interface is found to be up.

dialer map ip 192.0.2.0 name maui-nas-05 broadcast 5550111

!Dialer map for the BRI interface of the remote router.

dialer map ip 192.0.2.1 name maui-nas-05 broadcast 5550111

!Map statement for the route/network being watched by the

!dialer watch-list command.

!This address must exactly match the network configured with the

!dialer watch-list command.

!When the watched route disappears, this dials the specified phone number.

dialer watch-group 8

!Enable Dialer Watch on this backup interface.

!Watch the route specified with dialer watch-list 8.

dialer-group 1

!Apply interesting traffic defined in dialer-list 1.

isdn switch-type basic-ni

isdn spid1 51255522220101 5550112

isdn spid2 51255522230101 5550112

ppp authentication chap

!Use chap authentication.

!

router ospf 5

log-adjacency-changes

network 209.165.200.230 255.255.255.224 area 0

network 209.165.200.231 255.255.255.224 area 0

network 209.165.200.232 255.255.255.224 area 0

network 209.165.200.233 255.255.255.224 area 0

!

ip classless

no ip http server

!

dialer watch-list 8 ip 209.165.200.234 255.255.255.224

!This defines the route(s) to be watched.

!This exact route(including subnet mask) must exist in the routing table.

!Use the dialer watch-group 8 command to apply this list to the backup interface.

access-list 101 remark Define Interesting Traffic

access-list 101 deny ospf any any

!Mark OSPF as uninteresting.

!This will prevent OSPF hellos from keeping the link up.

Access-list 101 permit ip any any

dialer-list 1 protocol ip list 101

!Interesting traffic is defined by access-list 101.

!This is applied to BRI0 using dialer-group 1.

!

line con 0

login authentication NO_AUTHEN

transport input none

line vty 0 4

!

end

Configuration for maui-nas-05

maui-nas-05# show running-config

Building configuration...

Current configuration:

!

version 12.1

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname maui-nas-05

!

aaa new-model

aaa authentication login default local

aaa authentication login NO_AUTHEN none

aaa authentication ppp default local

! -- This is basic AAA configuration for PPP calls.

Enable secret 5 <deleted>

!

username maui-soho-01 password 0 cisco

!Username for remote router (maui-soho-01) and shared secret.

!Shared secret(used for CHAP authentication) must be the same on both sides.

!

ip subnet-zero

!

isdn switch-type basic-ni

!

interface Loopback0

ip address 209.165.200.230 255.255.255.224

!

interface Ethernet0/0

ip address 209.165.200.231 255.255.255.224

!

interface Ethernet0/1

no ip address

shutdown

!

interface BRI1/0

!Backup link.

ip address 209.165.200.231 255.255.255.224

encapsulation ppp

dialer map ip 172.20.10.2 name maui-soho-01 broadcast

!Dialer map with IP address and authenticated username for remote destination.

!The name should match the authentication username provided by the remote side.

!The dialer map statement is used even though this router is not dialing out.

Dialer-group 1

!Apply interesting traffic defined in dialer-list 1.

isdn switch-type basic-ni

isdn spid1 51255501110101 5550111

isdn spid2 51255501120101 5550112

ppp authentication chap

!

.

.

.

!

interface Serial2/0

ip address 209.165.200.232 255.255.255.224

encapsulation ppp

clockrate 64000

ppp authentication chap

!

.

.

.

!

router ospf 5

network 209.165.200.230 255.255.255.224 area 0

network 209.165.200.231 255.255.255.224 area 0

network 209.165.200.232 255.255.255.224 area 0

network 209.165.200.233 255.255.255.224 area 0

default-information originate

!

ip classless

ip route 209.165.200.229 255.255.255.224 Ethernet0/0

no ip http server

!

dialer-list 1 protocol ip permit

!This defines all IP traffic as interesting.

!

line con 0

login authentication NO_AUTHEN

transport input none

line 97 102

line aux 0

line vty 0 4

!

end

Configuring Dialer Watch with Cisco IOS Release 12.3(11)T and Later Releases: Example

command.

Configuration for maui-soho-01

maui-soho-01# show running-config

Building configuration...

Current configuration : 1546 bytes

!

version 12.4

no service single-slot-reload-enable

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname maui-soho-01

!

logging rate-limit console 10 except errors

aaa new-model

aaa authentication login default local

aaa authentication login NO_AUTHEN none

aaa authentication ppp default local

!This is basic AAA configuration for PPP calls.

enable secret 5 <deleted>

!

username maui-nas-05 password 0 cisco

!Username for remote router (maui-nas-05) and shared secret.

!Shared secret(used for CHAP authentication) must be the same on both sides.

ip subnet-zero

no ip finger

!

isdn switch-type basic-ni

!

interface Loopback0

ip address 209.165.200.225 255.255.255.224

!

interface Ethernet0

ip address 209.165.200.226 255.255.255.224

!

interface Serial0

!Primary link.

ip address 209.165.200.227 255.255.255.224

encapsulation ppp

ppp authentication chap

!

interface BRI0

ip address 209.165.200.228 255.255.255.224

!IP address for the BRI interface (backup link).

encapsulation ppp

dialer idle-timeout 30

!Idle timeout(in seconds)for this backup link.

!Dialer watch checks the status of the primary link every time the

!idle-timeout expires.

dialer map ip 192.0.2.1 name maui-nas-05 broadcast 5550111

!Dialer map for the BRI interface of the remote router.

dialer map ip 192.0.2.2 name maui-nas-05 broadcast 5550111

!Map statement for the route/network being watched by the

!dialer watch-list command.

!This address must exactly match the network configured with the

!dialer watch-list command.

!When the watched route disappears, this dials the specified phone number.

dialer watch-group 8

!Enable Dialer Watch on this backup interface.

!Watch the route specified with dialer watch-list 8.

dialer-group 1

!Apply interesting traffic defined in dialer-list 1.

isdn switch-type basic-ni

isdn spid1 51255522220101 5552222

isdn spid2 51255522230101 5552223

ppp authentication chap

!Use chap authentication.

dialer watch-list 8 delay disconnect 15

!Delays disconnecting the backup interface for 15 seconds after the

!primary interface is found to be up.

!

router ospf 5

log-adjacency-changes

network 209.165.200.225 255.255.255.224 area 0

network 209.165.200.226 255.255.255.224 area 0

network 209.165.200.227 255.255.255.224 area 0

network 209.165.200.228 255.255.255.224 area 0

!

ip classless

no ip http server

!

dialer watch-list 8 ip 209.165.200.229 255.255.255.224

!This defines the route(s) to be watched.

!This exact route(including subnet mask) must exist in the routing table.

!Use the dialer watch-group 8 command to apply this list to the backup interface.

access-list 101 remark Define Interesting Traffic

access-list 101 deny ospf any any

!Mark OSPF as uninteresting.

!This will prevent OSPF hellos from keeping the link up.

Access-list 101 permit ip any any

dialer-list 1 protocol ip list 101

!Interesting traffic is defined by access-list 101.

!This is applied to BRI0 using dialer-group 1.

!

line con 0

login authentication NO_AUTHEN

transport input none

line vty 0 4

!

end

Configuration for maui-nas-05

maui-nas-05# show running-config

Building configuration...

Current configuration:

!

version 12.4

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname maui-nas-05

!

aaa new-model

aaa authentication login default local

aaa authentication login NO_AUTHEN none

aaa authentication ppp default local

! -- This is basic AAA configuration for PPP calls.

Enable secret 5 <deleted>

!

username maui-soho-01 password 0 cisco

!Username for remote router (maui-soho-01) and shared secret.

!Shared secret(used for CHAP authentication) must be the same on both sides.

!

ip subnet-zero

!

isdn switch-type basic-ni

!

interface Loopback0

ip address 209.165.200.225 255.255.255.224

!

interface Ethernet0/0

ip address 209.165.200.226 255.255.255.224

!

interface Ethernet0/1

no ip address

shutdown

!

interface BRI1/0

!Backup link.

ip address 209.165.200.227 255.255.255.224

encapsulation ppp

dialer map ip 192.0.2.2 name maui-soho-01 broadcast

!Dialer map with IP address and authenticated username for remote destination.

!The name should match the authentication username provided by the remote side.

!The dialer map statement is used even though this router is not dialing out.

Dialer-group 1

!Apply interesting traffic defined in dialer-list 1.

isdn switch-type basic-ni

isdn spid1 51255501110101 5550111

isdn spid2 51255501120101 5550112

ppp authentication chap

!

! <<-- irrelevant output removed

!

interface Serial2/0

ip address 192.168.10.1 255.255.255.252

encapsulation ppp

clockrate 64000

ppp authentication chap

!

! <<-- irrelevant output removed

!

router ospf 5

network 209.165.200.225 255.255.255.224 area 0

network 209.165.200.226 255.255.255.224 area 0

network 209.165.200.227 255.255.255.224 area 0

network 209.165.200.228 255.255.255.224 area 0

default-information originate

!

ip classless

ip route 209.165.200.225 255.255.255.224 Ethernet0/0

no ip http server

!

dialer-list 1 protocol ip permit

!This defines all IP traffic as interesting.

!

line con 0

login authentication NO_AUTHEN

transport input none

line 97 102

line aux 0

line vty 0 4

!

end

Additional References

The following sections provide references related to the Configuring Dial Backup Using Dialer Watch.

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Commands List, All Releases

Dial commands

Standards

Standard

Title

No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.

—

MIBs

MIB

MIBs Link

No new or modified MIBs are supported, and support for existing MIBs has not been modified.

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

RFCs

RFC

Title

No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.

—

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

Feature Information for Configuring Dial Backup Using Dialer Watch

lists the release history for this feature.

Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.

. An account on Cisco.com is not required.

Note Table 1 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.

Table 1 Feature Information for Configuring Dial Backup Using Dialer Watch

Feature Name

Releases

Feature Information

Dialer Watch

11.3(2)T

The Dialer Watch feature provides enhancements to the Hot Standby Router Protocol (HSRP) function. This feature provides the backup router and backup links as soon as the primary routers and links become inactive.

.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 1998–2010 Cisco Systems, Inc. All rights reserved.

Dialer Watch Connect Delay

Feature History

Release

Modification

12.2(8)T

This feature was introduced.

This document describes the Dialer Watch Connect Delay feature in Cisco IOS Release 12.2(8)T and includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Prerequisites

- Configuration Tasks

- Verifying Dialer Watch Connect Delay Configuration

- Configuration Examples

- Command Reference

Feature Overview

The Dialer Watch Connect Delay feature introduces the ability to configure a delay in bringing up a secondary link when a primary link that is monitored by Dialer Watch goes down and is removed from the routing table. Previously, the router would instantly dial a secondary route without allowing time for the primary route to come back up. When the Dialer Watch Connect Delay feature is configured, the router will check for availability of the primary link at the end of the specified delay time before dialing the secondary link.

Benefits

The Dialer Watch Connect Delay feature allows users greater control over the use of a secondary link on monitored IP addresses or networks. Configuring the router to delay bringing up a secondary link when the watched primary link goes down will allow time for the primary link to be restored in the event of a temporary outage.

Related Documents

- The part “ Dial-on-Demand Routing Configuration ” in the Cisco IOS Dial Technologies Configuration Guide, Release 12.2.

- The chapter “ Configuring Dial Backup Using Dialer Watch ” in the Cisco IOS Dial Technologies Configuration Guide, Release 12.2.

- Cisco IOS Dial Technologies Command Reference , Release 12.2

Supported Platforms

- Cisco 805

- Cisco 806

- Cisco 820

- Cisco 827

- Cisco 828

- Cisco 1600 series

- Cisco 1700

- Cisco 1710

- Cisco 2600 series

- Cisco 3640

- Cisco 3660

- Cisco 7100

- Cisco 7200

- Cisco 7500

- soho 78

- mc3810

- C6MSFC2

Determining Platform Support Through Cisco Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Cisco Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.

.

Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:

Supported Standards, MIBs, and RFCs

Standards

No new or modified standards are supported by this feature.

MIBs

No new or modified MIBs are supported by this feature.

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

RFCs

No new or modified RFCs are supported by this feature.

Prerequisites

Dial-on-Demand routing (DDR) must be configured and Dialer Watch must be enabled. For more information on configuring DDR, refer to the following documents:

- The part “ Dial-on-Demand Routing Configuration ” in the Cisco IOS Dial Technologies Configuration Guide, Release 12.2.

- The chapter “ Configuring Dial Backup Using Dialer Watch ” in the Cisco IOS Dial Technologies Configuration Guide, Release 12.2.

Configuration Tasks

See the following sections for configuration tasks for the Dialer Watch Connect Delay feature. Each task in the list is identified as either required or optional.

- Configuring a Delay Before Activating a Secondary Link (required)

- Configuring a Delay Before Disconnecting the Secondary Link (optional)

Configuring a Delay Before Activating a Secondary Link

To configure the router to delay before dialing a secondary link when the primary link goes down, use the following command in global configuration mode:

Command

Purpose

Configures a delay in dialing the secondary link when the primary link becomes unavailable.

- The delay connect keyword phrase specifies that the router will delay dialing the secondary link when the primary link becomes unavailable.

- The connect-time argument specifies the time, in seconds, after which the router rechecks for availability of the primary link. If the primary link is still unavailable, the secondary link is then dialed. Valid times range from 1 to 2147483.

Configuring a Delay Before Disconnecting the Secondary Link

To configure the router to delay before disconnecting a secondary link when the primary link is reestablished, use the following command in global configuration mode:

Command

Purpose

Configures a delay in disconnecting the secondary link after detecting availability of the primary link.

- The delay disconnect keyword phrase specifies that the router will delay disconnecting the secondary link after detecting availability of the primary link.

- The disconnect-time argument specifies the time, in seconds, after which the router disconnects the secondary link once the primary link has been detected. Valid times range from 1 to 2147483.

Verifying Dialer Watch Connect Delay Configuration

To verify the cofiguration fo the Dialer Watch Connect Delay feature, perform the following steps:

command to verify the configuration of Dialer Watch connect and disconnect delays:

router# show running-config

dialer watch-list 1 ip 10.1.1.1 255.0.0.0

dialer watch-list 1 delay connect 20

dialer watch-list 1 delay disconnect 20

dialer-list 1 protocol ip permit

command:

router# debug dialer

Connect Delay

------------------------

*Mar 1 04:29:16:DDR:Dialer Watch:watch-group = 1

*Mar 1 04:29:16:DDR: network 5.0.0.0/255.0.0.0 DOWN,

*Mar 1 04:29:16:DDR: network 4.0.0.0/255.0.0.0 DOWN,

*Mar 1 04:29:16:DDR: network 3.0.0.0/255.0.0.0 DOWN,

*Mar 1 04:29:16:DDR: primary DOWN

*Mar 1 04:29:16:DDR:Dialer Watch: Primary of group 1 DOWN - start dial-backup timer

Disconnect delay

------------------------

*Mar 1 04:31:11:BR2/0:1 DDR:idle timeout

*Mar 1 04:31:11:DDR:Dialer Watch:watch-group = 1

*Mar 1 04:31:11:DDR: network 5.0.0.0/255.0.0.0 UP,

*Mar 1 04:31:11:DDR: primary UP

*Mar 1 04:31:11:BR2/0:1 DDR:starting watch disconnect timer

*Mar 1 04:31:46:BR2/0:1 DDR:watch disconnect timeout

*Mar 1 04:31:46:DDR:Dialer Watch:watch-group = 1

*Mar 1 04:31:46:DDR: network 5.0.0.0/255.0.0.0 UP,

*Mar 1 04:31:46:DDR: primary UP

Configuration Examples

This section provides the following configuration examples:

- Configuring a Delay Before Activating a Secondary Link Example

- Configuring a Delay Before Disconnecting a Secondary Link Example

Configuring a Delay Before Activating a Secondary Link Example

The following example configures the router to wait 10 seconds before verifying that the primary link is still down and dialing a secondary link:

dialer watch-list 1 ip 10.1.1.0 255.255.255.0

dialer watch-list 1 delay connect 10

Configuring a Delay Before Disconnecting a Secondary Link Example

The following example configures the router to wait 10 seconds to disconnect a secondary link once the primary link has been reestablished:

dialer watch-list 1 ip 10.1.1.0 255.255.255.0

dialer watch-list 1 delay disconnect 10

Command Reference

- dialer watch-list delay

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007–2009 Cisco Systems, Inc. All rights reserved.

VRF Aware Dialer Watch

The VRF Aware Dialer Watch feature enhances dialer watch functionality by allowing an IP address and VPN routing and forwarding (VRF) instance pair to be watched for dial backup.

Feature History for the VRF Aware Dialer Watch Feature

Release

Modification

12.3(7)T

This feature was introduced.

Finding Support Information for Platforms and Cisco IOS Software Images

at the login dialog box and follow the instructions that appear.

Contents

- Information About VRF Aware Dialer Watch

- How to Configure VRF Aware Dialer Watch

- Configuration Examples for VRF Aware Dialer Watch

- Additional References

- Command Reference

Information About VRF Aware Dialer Watch

To configure the VRF Aware Dialer Watch feature, you need to understand the following concepts:

- How VRF Aware Dialer Watch Works

- VRF Aware Dialer Watch Typical Scenario

How VRF Aware Dialer Watch Works

The Cisco IOS Dialer Watch software feature integrates dial backup with routing capabilities. The Dialer Watch dial backup technology uses a route called watched-route, and whenever the watched-route entry is lost from a routing table, a new a backup link is brought up.

With the VRF Aware Dialer Watch feature introduced in Cisco IOS Release 12.3(7)T, you configure the watched-route as an IP address and VRF pair. A VRF is a per-Virtual Private Network (VPN) routing information repository that defines the VPN membership of a customer site attached to a network access server. A VRF consists of an IP routing table, a derived Cisco Express Forwarding (CEF) table, a set of interfaces that use the forwarding table, and a set of rules and routing protocol parameters that control the information that is included in the routing table. A separate set of routing and CEF tables is maintained for each VPN customer.

The corresponding VRF table configured in the VRF Aware Dialer Watch feature is used to detect when watched-route for the VRF has gone down. The original Dialer Watch feature looked only at the global routing table to determine if the watched route had gone down. The VRF Aware Dialer Watch feature allows configuring multiple VRFs apart from the global routing table. A secondary link will be brought up when the watched route in the corresponding VRF table goes down.

It is important to note that the VRF might have overlapping address space, as follows: At the provider edge (PE) router, each customer edge (CE) router—the router that is part of the customer network and that interfaces to a PE router—will have a corresponding VRF associated with it. Further, two CE routers might be using the same address space, so that the corresponding VRFs at the PE router will have overlapping address space. For this reason, you must configure the watched route as an IP address and VRF name pair, where the IP address is the watched IP address and the VRF name is the routing and forwarding instance to which the IP address belongs. Configuring the Dialer Watch feature with only the IP address did not ensure that the correct CE route would be dialed when a watched route went down. Configuring the new VRF Aware Dialer Watch feature with an IP address and VRF name pair ensures that the VRF table corresponding to the routing and forwarding instance to which the IP address belongs is found and the correct CE is dialed.

VRF Aware Dialer Watch Typical Scenario

Figure 1 shows a typical configuration that uses the VRF Aware Dialer Watch feature.

Figure 1 VRF Aware Dialer Watch Typical Configuration

A typical scenario for the VRF Aware Dialer Watch feature follows:

- A VRF router learns the route to the CE from a PE.

- The VRF router watches these learned routes to the CEs.

- The primary link between a PE and CE goes down.

- The watched route goes down in the VRF router.

- Dialer Watch call is initiated to the corresponding CE.

The backup link will be bound to the correct VRF. In configurations with a dialer profile, the dialer profile interface is statically bound to the corresponding VRF. In configurations without a dialer profile, a virtual access interface is created dynamically that is bound to the VRF.

How to Configure VRF Aware Dialer Watch

This section contains the following required task to configure the VRF Aware Dialer Watch feature:

- Configuring the Dialer Watch List (required)

Configuring the Dialer Watch List

commands, to specify a list of watched routes.

interface configuration command, and the standard commands required to enable the router to perform dial-on-demand routing in addition to the Dialer Watch commands. Refer to Cisco IOS configuration guides and command references listed in the “Related Documents” section for additional information. See the “Configuration Examples for VRF Aware Dialer Watch” section for examples of how the VRF Aware Dialer Watch feature can be configured.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

}

Router(config)# dialer watch-list 1 ip 10.2.1.0 255.255.255.0 vrf v1

Specifies the list of watched routes of IP addresses or IP address and VRF pairs to be monitored by Dialer Watch.

- group-number —Matches the group number set in a dialer watch-group interface configuration command.

- ip ip-address address-mask —Specifies the IP address or address range and address mask to be applied to the list.

- vrf vrf-name —(Optional) Specifies a watched route using the VRF table named in the vrf-name argument.

- delay route-check initial seconds —Number of seconds after which the router ensures that the primary route is up once initial startup is complete.

Note You can define one watch route that watches the same IP address, but belongs to a different VRF, in a single watch list.

Step 4

Router(config)# exit

Exits global configuration mode.

- Use the end command to save your configuration and leave configuration mode.

Configuration Examples for VRF Aware Dialer Watch

This section contains the following examples. See the “Related Documents” section for additional documents that contain examples that will show use of configuring VRF aware dialer maps.

- VRF Aware Dialer Watch on a Legacy Dialer Configuration: Example

- VRF Aware Dialer Watch on a Dialer Rotary Group: Example

- VRF Aware Dialer Watch on a Dialer Profile Configuration: Example

VRF Aware Dialer Watch on a Legacy Dialer Configuration: Example

The following example specifies a pair of watched routes in a legacy dialer configuration. In this configuration, watch lists 1 and 2 are both watching the same IP address, but belong to different VRFs.

interface BRI3/0

ip address 10.0.2.2 255.255.255.0

encapsulation ppp

dialer map 10.1.2.0 vrf v1 3xxxxxx

dialer map 10.1.2.0 vrf v2 4xxxxxx

dialer-group 1

dialer watch-group 1

dialer watch-group 2

isdn switch-type ntt

ppp authentication chap

!

dialer watch-list 1 ip 10.2.1.0 255.255.255.0 vrf v1

dialer watch-list 2 ip 10.2.1.0 255.255.255.0 vrf v2

VRF Aware Dialer Watch on a Dialer Rotary Group: Example

The following example specifies a pair of watched routes in a dialer rotary group configuration. In this configuration, watch lists 1 and 2 are both watching the same IP address, but belong to different VRFs.

interface BRI3/0

no ip address

encapsulation ppp

dialer rotary-group 1

isdn switch-type ntt

ppp authentication chap

!

interface Dialer1

ip address 10.0.2.2 255.255.255.0

encapsulation ppp

dialer remote-name c3640-B

dialer watch-disable 30

dialer map 10.1.2.0 vrf v1 3xxxxxx

dialer map 10.1.2.0 vrf v2 4xxxxxx

dialer watch-group 1

dialer watch-group 2

dialer-group 1

ppp authentication chap

!

dialer watch-list 1 ip 10.2.1.0 255.255.255.0 vrf v1

dialer watch-list 2 ip 10.2.1.0 255.255.255.0 vrf v2

VRF Aware Dialer Watch on a Dialer Profile Configuration: Example

The following example specifies a pair of watched routes in a dialer profile configuration. In this configuration, watch lists 1 and 2 are both watching the same IP address, but belong to different VRFs.

interface BRI3/0

no ip address

encapsulation ppp

dialer pool-member 1

isdn switch-type ntt

ppp authentication chap

!

!

interface Dialer1

ip vrf forwarding v1

ip address 10.0.2.2 255.255.255.0

encapsulation ppp

dialer pool 1

dialer remote-name c3640-B

dialer watch-disable 30

dialer string 03xxxxxxx1

dialer caller 03xxxxxxx1 callback

dialer watch-group 1

dialer-group 1

ppp authentication chap

!

!

interface Dialer2

ip vrf forwarding v2

ip address 10.0.2.2 255.255.255.0

encapsulation ppp

dialer pool 1

dialer remote-name c3640-B

dialer watch-disable 30

dialer string 04xxxxxxx1

dialer caller 04xxxxxxx1 callback

dialer watch-group 2

dialer-group 1

ppp authentication chap

!

dialer watch-list 1 ip 10.2.1.0 255.255.255.0 vrf v1

dialer watch-list 2 ip 10.2.1.0 255.255.255.0 vrf v2

Additional References

The following sections provide references related to the VRF Aware Dialer Watch feature.

Related Documents

Related Topic

Document Title

Dialer Watch

Dialer commands

VRF-aware dialer maps

feature module

Standards

Standards

Title

None

—

MIBs

MIBs

MIBs Link

None

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

RFCs

RFCs

Title

None

—

Technical Assistance

Description

Link

Technical Assistance Center (TAC) home page, containing 30,000 pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.

Command Reference

.

- dialer watch-list

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

.Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001-2009 Cisco Systems, Inc. All rights reserved.

Configuring Dial Backup with Dialer Profiles

This chapter describes how to configure dialer interfaces, which can be configured as the logical intermediary between one or more physical interfaces and another physical interface that is to function as backup. It includes the following main sections:

- Dial Backup with Dialer Profiles Overview

- How to Configure Dial Backup with Dialer Profiles

- Configuration Example of Dialer Profile for ISDN BRI Backing Up Two Leased Lines

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

Dial Backup with Dialer Profiles Overview

A backup interface is an interface that stays idle until certain circumstances occur; then it is activated. Dialer interfaces can be configured to use a specific dialing pool; in turn, physical interfaces can be configured to belong to the same dialing pool.

See the section “Configuration Example of Dialer Profile for ISDN BRI Backing Up Two Leased Lines” at the end of this chapter for a comprehensive example of a dial backup interface using dialer profiles. In the example, one BRI functions as backup to two serial lines and can make calls to two different destinations.

How to Configure Dial Backup with Dialer Profiles

To configure a dialer interface and a specific physical interface to function as backup to other physical interfaces, perform the tasks in the following sections:

- Configuring a Dialer Interface (Required)

- Configuring a Physical Interface to Function As Backup (Required)

- Configuring Interfaces to Use a Backup Interface (Required)

Configuring a Dialer Interface

To configure the dialer interface that will be used as an intermediary between a physical interface that will function as backup interface and the interfaces that will use the backup, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Creates a dialer interface and begins interface configuration mode.

Step 2

Specifies IP unnumbered loopback.

Step 3

Specifies PPP encapsulation.

Step 4

Specifies the Challenge Handshake Authentication Protocol (CHAP) authentication name of the remote router.

Step 5

Specifies the remote destination to call.

Step 6

Specifies the dialing pool to use for calls to this destination.

Step 7

Assigns the dialer interface to a dialer group.

Configuring a Physical Interface to Function As Backup

To configure the physical interface that is to function as backup, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Specifies the interface and begins interface configuration mode.

Step 2

Specifies PPP encapsulation.

Step 3

arguments have the same value.

Step 4

Specifies CHAP authentication.

Configuring Interfaces to Use a Backup Interface

To configure one or more interfaces to use a backup interface, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Specifies the interface to be backed up and begins interface configuration mode.

Step 2

Specifies IP unnumbered loopback.

Step 3

Specifies the backup interface and begins interface configuration mode.

Step 4

Specifies delay between the physical interface going down and the backup being enabled, and between the physical interface coming back up and the backup being disabled.

Configuration Example of Dialer Profile for ISDN BRI Backing Up Two Leased Lines

The following example shows the configuration of a site that backs up two leased lines using one BRI. Two dialer interfaces are defined. Each serial (leased line) interface is configured to use one of the dialer interfaces as a backup. Both of the dialer interfaces use dialer pool 1, which has physical interface BRI 0 as a member. Thus, physical interface BRI 0 can back up two different serial interfaces and can make calls to two different sites.

interface dialer0

ip unnumbered loopback0

encapsulation ppp

dialer remote-name Remote0

dialer pool 1

dialer string 5551212

dialer-group 1

interface dialer1

ip unnumbered loopback0

encapsulation ppp

dialer remote-name Remote1

dialer pool 1

dialer string 5551234

dialer-group 1

interface bri 0

encapsulation PPP

dialer pool-member 1

ppp authentication chap

interface serial 0

ip unnumbered loopback0

backup interface dialer 0

backup delay 5 10

interface serial 1

ip unnumbered loopback0

backup interface dialer1

backup delay 5 10

ISDN Backup in MPLS Core

When a primary link is down in the Multiprotocol Label Switching (MPLS) core network, the ISDN Backup in MPLS Core feature allows a backup ISDN link on a dialer interface to be brought up to restore network connectivity. This feature ensures high availability of the link between two routers in the MPLS core by providing a backup mechanism.

Feature Specifications for the ISDN Backup in MPLS Core feature

Feature History

Release

Modification

12.3(2)T

This feature was introduced.

Supported Platforms

Cisco 3640 series, Cisco 7200 series

Finding Support Information for Platforms and Cisco IOS Software Images

at the login dialog box and follow the instructions that appear.

Contents

- Prerequisites for ISDN Backup in MPLS Core

- Restrictions for ISDN Backup in MPLS Core

- Information About ISDN Backup in MPLS Core

- How to Configure ISDN Backup in MPLS Core

- Configuration Examples for ISDN Backup in MPLS Core

- Additional References

Prerequisites for ISDN Backup in MPLS Core

You need to first configure the Dialer Persistent feature.

Restrictions for ISDN Backup in MPLS Core

- The ISDN Backup in MPLS Core feature works only with dialer profile configuration.

- The ISDN Backup in MPLS Core feature is available only for PPP encapsulation.

Information About ISDN Backup in MPLS Core

Before configuring and implementing the ISDN Backup for MPLS Core feature, you should understand the following concepts:

- How ISDN Backup in MPLS Core Works

- Benefits of ISDN Backup in MPLS Core Feature

How ISDN Backup in MPLS Core Works

, Release 12.3.

When the primary interface goes down, the dialer profile that is acting as the backup will bring up the backup interface without waiting for any interesting traffic because Dialer Persistent has been configured. Once the link to the destination is established, tagged packets will flow via the dialer interface.

Benefits of ISDN Backup in MPLS Core Feature

The ISDN Backup in MPLS Core feature provides MPLS switching support on dialer interfaces for ISDN backup in MPLS core networks. When you configure a backup ISDN link on a dialer interface, the dialer interface can be brought up to restore network connectivity when a primary link goes down in an MPLS core network.

How to Configure ISDN Backup in MPLS Core

This section contains the following procedures:

- Configuring Primary Interface for Backup

- Configuring the Dialer Profile as Backup Interface

- Verifying the ISDN Backup for MPLS Feature

Configuring Primary Interface for Backup

Perform this task to configure a primary interface backup.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# interface serial 1

Configures an interface type and enters interface configuration mode.

Step 4

Router(config-if)# backup interface dialer 1

Configures an interface as a secondary or dial backup interface.

Step 5

Router(config-if)# exit

Returns to global configuration mode.

Configuring the Dialer Profile as Backup Interface

Perform this task to configure the Dialer Persistent feature on the backup interface.

SUMMARY STEPS

(interface configuration)

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# interface dialer 1

Creates a dialer interface and enters interface configuration mode.

Step 4

Router(config-if)# encapsulation ppp

Specifies the encapsulation type.

Step 5

]

Router(config-if)# dialer persistent delay initial 20

Forces a dialer interface to be connected at all times, even in the absence of interesting traffic.

Step 6

Router(config-if)# tag-switching ip

Enables label switching of IPv4 packets on an interface.

Step 7

Router(config-if)# exit

Returns to global configuration mode.

Verifying the ISDN Backup for MPLS Feature

Perform this task to verify that you have correctly configured the ISDN Backup for MPLS feature.

SUMMARY STEPS

]

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# show mpls forwarding-table

Displays the contents of the MPLS FIB.

Step 3

]

Router(config)# show mpls interfaces dialer detail

Displays the contents of the Multiprotocol Label Switching (MPLS) label forwarding information base (LFIB).

Step 4

Router(config)# exit

Returns to global configuration mode.

Configuration Examples for ISDN Backup in MPLS Core

This section provides the following configuration example:

- ISDN Backup for MPLS Example

ISDN Backup for MPLS Example

The following example shows the interface Dialer 1 being configured as the backup interface.

interface Serial1

backup interface Dialer1

ip address 172.16.1.1 255.0.0.0

mpls ip

encapsulation ppp

!

interface Serial0:23

no ip address

encapsulation ppp

dialer pool-member 1

ppp authentication chap

!

interface Dialer1

ip address 172.16.1.3 255.0.0.0

encapsulation ppp

dialer pool 1

dialer remote-name P1

dialer string 1114

dialer persistent

dialer-group 1

mpls ip

ppp authentication chap

!

Additional References

The following sections provide additional references related to the ISDN Backup in MPLS Core feature.

Related Documents

Related Topic

Document Title

Dialer Persistent feature

Dial-Backup Configuration

Standards

Standards

Title

None

—

MIBs

MIBs

MIBs Link

None

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

RFCs

RFCs

Title

None

Technical Assistance

Description

Link

Technical Assistance Center (TAC) home page, containing 30,000 pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007–2009 Cisco Systems, Inc. All rights reserved.

Configuring Cisco Easy IP

This chapter describes how to configure the Cisco Easy IP feature. It includes the following main sections:

- Cisco Easy IP Overview

- How to Configure Cisco Easy IP

- Configuration Examples for Cisco Easy IP

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

Cisco Easy IP Overview

Cisco Easy IP enables transparent and dynamic IP address allocation for hosts in remote environments using the following functionality:

- Cisco Dynamic Host Configuration Protocol (DHCP) server

- Port Address Translation (PAT), a subset of Network Address Translation (NAT)

- Dynamic PPP/IP Control Protocol (PPP/IPCP) WAN interface IP address negotiation

With the Cisco IOS Easy IP, a Cisco router automatically assigns local IP addresses to remote hosts (such as small office, home office or SOHO routers) using DHCP with the Cisco IOS DHCP server, automatically negotiates its own registered IP address from a central server via PPP/IPCP, and uses PAT functionality to enable all SOHO hosts to access the Internet using a single registered IP address. Because Cisco IOS Easy IP uses existing port-level multiplexed NAT functionality within Cisco IOS software, IP addresses on the remote LAN are invisible to the Internet, making the remote LAN more secure.

Cisco Easy IP provides the following benefits:

- Minimizes Internet access costs for remote offices

- Minimizes configuration requirements on remote access routers

- Enables transparent and dynamic IP address allocation for hosts in remote environments

- Improves network security capabilities at each remote site

- Conserves registered IP addresses

- Maximizes IP address manageability

Figure 1 shows a typical scenario for using the Cisco Easy IP feature.

Figure 1 Telecommuter and Branch Office LANs Using Cisco Easy IP

Steps 1 through 4 show how Cisco Easy IP works:

Step 1 When a SOHO host generates “interesting” traffic (as defined by Access Control Lists) for dialup (first time only), the Easy IP router requests a single registered IP address from the access server at the central site via PPP/IPCP. (See Figure 2.)

Figure 2 Cisco Easy IP Router Requests a Dynamic Global IP Address

Step 2 The central site router replies with a dynamic global address from a local DHCP IP address pool. (See Figure 3.)

Figure 3 Dynamic Global IP Address Delivered to the Cisco Easy IP Router

Step 3 The Cisco Easy IP router uses port-level NAT functionality to automatically create a translation that associates the registered IP address of the WAN interface with the private IP address of the client. (See Figure 4.)

Figure 4 Port-Level NAT Functionality Used for IP Address Translation

Step 4 The remote hosts contain multiple static IP addresses while the Cisco Easy IP router obtains a single registered IP address using PPP/IPCP. The Cisco Easy IP router then creates port-level multiplexed NAT translations between these addresses so that each remote host address (inside private address) is translated to a single external address assigned to the Cisco Easy IP router. This many-to-one address translation is also called port-level multiplexing or PAT. Note that the NAT port-level multiplexing function can be used to conserve global addresses by allowing the remote routers to use one global address for many local addresses. (See Figure 5.)

Figure 5 Multiple Private Internal IP Addresses Bound to a Single Global IP Address

How to Configure Cisco Easy IP

Before using Cisco Easy IP, perform the following tasks:

- Configure the ISDN switch type and service provider identifier (SPID), if using ISDN.

- Configure the static route from LAN to WAN interface.

- Configure the Cisco IOS DHCP server.

.

for DHCP configuration instructions.

In its most simple configuration, a Cisco Easy IP router or access server will have a single LAN interface and a single WAN interface. Based on this model, to use Cisco Easy IP you must perform the tasks in the following sections:

- Defining the NAT Pool (Required)

- Configuring the LAN Interface (Required)

- Defining NAT for the LAN Interface (Required)

- Configuring the WAN Interface (Required)

- Enabling PPP/IPCP Negotiation (Required)

- Defining NAT for the Dialer Interface (Required)

- Configuring the Dialer Interface (Required)

For configuration examples, see the section “Configuration Examples for Cisco Easy IP” at the end of this chapter.

Defining the NAT Pool

The first step in enabling Cisco Easy IP is to create a pool of internal IP addresses to be translated. To define the NAT pool, use the following commands in global configuration mode:

Command

Purpose

Step 1

]

Defines a standard access list permitting those addresses that are to be translated.

Step 2

Establishes dynamic source translation, identifying the access list defined in the prior step.

.

Configuring the LAN Interface

To configure the LAN interface, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Selects a specific LAN interface and begins interface configuration mode.

Step 2

Defines the IP address and subnet mask for this interface.

.

Defining NAT for the LAN Interface

To ensure that the LAN interface is connected to the inside network (and therefore subject to NAT), use the following command in interface configuration mode:

Command

Purpose

Defines the interface as internal for NAT.

Configuring the WAN Interface

To configure the WAN interface, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Selects the WAN interface and begins interface configuration mode.

Step 2

Removes any associated IP address from this interface.

Step 3

Selects PPP as the encapsulation method for this interface.

Step 4

Binds the WAN interface to the dialer interface.

Enabling PPP/IPCP Negotiation

To enable PPP/IPCP negotiation on the dialer interface, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Selects the dialer interface and begins interface configuration mode.

Step 2

Enables PPP/IPCP negotiation for this interface.

Defining NAT for the Dialer Interface

To define that the dialer interface is connected to the outside network, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Selects the dialer interface and begins interface configuration mode.

Step 2

Defines the interface as external for network address translation.

Configuring the Dialer Interface

To configure the dialer interface information, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Selects the dialer interface and begins interface configuration mode.

Step 2

Specifies for a dialer interface the length of time the interface waits for a carrier before timing out.

Step 3

Creates a dialer hold queue and specifies the number of packets to be held in it.

Step 4

Specifies the remote router Challenge Handshake Authentication Protocol (CHAP) authentication name.

Step 5

Specifies the amount of idle time that can pass before calls to the central access server are disconnected. See the next section “Timeout Considerations,” for more details on this setting.

Step 6

Specifies the telephone number required to reach the central access server.

Step 7

Specifies the dialing pool to use.

Step 8

Assigns the dialer interface to a dialer group.

Timeout Considerations

Dynamic NAT translations time out automatically after a predefined default period. Although configurable, with the port-level NAT functionality in Cisco Easy IP, Domain Name System (DNS) User Datagram Protocol (UDP) translations time out after 5 minutes, while DNS translations time out after 1 minute by default. TCP translations time out after 24 hours by default, unless a TCP Reset (RST) or TCP Finish (FIN) is seen in the TCP stream, in which case the translation times out after 1 minute.

If the Cisco IOS Easy IP router exceeds the dialer idle-timeout period, it is expected that all active TCP sessions were previously closed via an RST or FIN. NAT times out all TCP translations before the Cisco Easy IP router exceeds the dialer idle-timeout period. The router then renegotiates another registered IP address the next time the WAN link is brought up, thereby creating new dynamic NAT translations that bind the IP addresses of the LAN host to the newly negotiated IP address.

Configuration Examples for Cisco Easy IP

The following example shows how to configure BRI interface 0 (shown as interface bri0) to obtain its IP address via PPP/IPCP address negotiation:

! The following command defines the NAT pool.

ip nat inside source list 101 interface dialer1 overload

!

! The following commands define the ISDN switch type.

isdn switch type vn3

isdn tei-negotiation first-call

!

! The following commands define the LAN address and subnet mask.

interface ethernet0

ip address 10.0.0.4 255.0.0.0

! The following command defines ethernet0 as internal for NAT.

ip nat inside

!

! The following commands binds the physical interface to the dialer1 interface.

interface bri0

no ip address

encapsulation ppp

dialer pool-member 1

!

interface dialer1

!

! The following command enables PPP/IPCP negotiation for this interface.

ip address negotiated

encapsulation ppp

!

! The following command defines interface dialer1 as external for NAT.

ip nat outside

dialer remote-name dallas

dialer idle-timeout 180

!

! The following command defines the dialer string for the central access server.

dialer string 4159991234

dialer pool 1

dialer-group 1

!

! The following commands define the static route to the WAN interface.

ip route 0.0.0.0 0.0.0.0 dialer1

access-list 101 permit ip 10.0.0.0 0.255.255.255 any

dialer-list 1 protocol ip list 101

The following example shows how to configure an asynchronous interface (interface async1) to obtain its IP address via PPP/IPCP address negotiation:

! This command defines the NAT pool.

ip nat inside source list 101 interface dialer 1 overload

!

! The following commands define the LAN IP address and subnet mask.

interface ethernet0

ip address 10.0.0.4 255.0.0.0

!

! The following command defines ethernet0 as internal for NAT.

ip nat inside

!

! The following commands bind the physical dialer1 interface.

interface async1

no ip address

encapsulation ppp

async mode dedicated

dialer pool-member 1

!

interface dialer1

!

! The following command enables PPP/IPCP negotiation for this interface.

ip address negotiated

encapsulation ppp

!

! The following command defines interface dialer1 as external for NAT.

ip nat outside

dialer wait-for-carrier-time 30

dialer hold-queue 10

dialer remote-name dallas

dialer idle-timeout 180

!

! The following command defines the dialer string for the central access server.

dialer string 4159991234

dialer pool 1

dialer-group 1

!

! The following commands define the static route to the WAN interface.

ip route 0.0.0.0 0.0.0.0 dialer1

access-list 101 permit ip 10.0.0.0 0.255.255.255 any

dialer-list 1 protocol ip list 101

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

.Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007–2009 Cisco Systems, Inc. All rights reserved.

Virtual Interface Template Service

First Published: May 10, 2001

Last Updated: November 20, 2014

The Virtual Interface Template Service feature provides a generic service that can be used to apply predefined interface configurations (virtual interface template services) in creating and freeing virtual access interfaces dynamically, as needed.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the “Feature Information for Virtual Interface Template” section.

An account on Cisco.com is not required.

Contents

- Restrictions for Virtual Interface Template Service

- Information About Virtual Interface Template Service

- How to Configure a Virtual Interface Template

- Configuration Examples for Virtual Interface Template

- Feature Information for Virtual Interface Template

Restrictions for Virtual Interface Template Service

The following restrictions apply for configuring the virtual interface template service feature:

- Although a system can generally support many virtual interface template services, one template for each virtual access application is a more realistic limit.

- When in use, each virtual access interface cloned from a template requires the same amount of memory as a serial interface. Limits to the number of virtual access interfaces that can be configured are determined by the platform.

- You cannot reuse virtual interface templates. You need to create different templates for different interface configurations.

- You cannot directly configure virtual access interfaces. You need to configure a virtual access interface by configuring a virtual interface template service or including the configuration information of the user on an authentication, authorization, and accounting (AAA) server. However, information about an in-use virtual access interface can be displayed, and the virtual access interface can be cleared.

- Virtual interface templates provide no direct value to you; they must be applied to or associated with a virtual access feature using a command with the virtual-template keyword.

command creates the virtual interface template service.

or a Cisco IOS master commands list.

Information About Virtual Interface Template Service

To configure the virtual interface template service, you should understand the following concepts:

- Virtual Interface Template Service Overview

- Benefits of Virtual Interface Template Service

- Features that Use Virtual Interface Template Service

- Selective Virtual Access Interface Creation

Virtual Interface Template Service Overview

Virtual interface template services can be configured independently of any physical interface and applied dynamically, as needed, to create virtual access interfaces. When a user dials in, a predefined configuration template is used to configure a virtual access interface; when the user is done, the virtual access interface goes down and the resources are freed for other dial-in uses.

a virtual interface template service), used, and then freed when no longer needed.

Virtual interface template services are one possible source of configuration information for a virtual access interface.

Each virtual access interface can clone from only one template. But some applications can take configuration information from multiple sources; The result of using template and AAA configuration sources is a virtual access interface uniquely configured for a specific dial-in user.

Figure 1 illustrates that a device can create a virtual access interface by first using the information from a virtual interface template service (if any is defined for the application) and then using the information in a per-user configuration.

Figure 1 Possible Configuration Sources for Virtual Access Interfaces

Benefits of Virtual Interface Template Service

The virtual interface template service is intended primarily for customers with large numbers of dial-in users and provides the following benefits:

- Easy maintenance: It allows customized configurations to be predefined and then applied dynamically when the specific need arises.

- Scalability: It allows interface configuration to be separated from physical interfaces. Virtual interfaces can share characteristics, no matter what specific type of interface the user called on.

- Consistency and configuration ease: It allows the same predefined template to be used for all users dialing in for a specific application.

- Efficient device operation: It frees the virtual access interface memory for another dial-in use when the call from the user ends.

Features that Use Virtual Interface Template Service

The following features use virtual interface template service to create virtual access interfaces dynamically:

- Virtual Private Dialup Networks (VPDNs)

- Virtual interface templates for protocol translation

- PPP over ATM

Virtual interface templates are supported on all platforms that support these features.

To create and configure a virtual interface template interface, compete the tasks in the “Creating and Configuring a Virtual Interface Template” section. To apply a virtual interface template service, refer to the specific feature that applies the virtual interface template.

All prerequisites depend on the feature that is applying a virtual interface template to create a virtual access interface. Virtual interface template services themselves have no other prerequisites.

Selective Virtual Access Interface Creation

You can configure a device to automatically determine whether to create a virtual access interface for each inbound connection. In particular, a call that is received on a physical asynchronous interface that uses a AAA per-user configuration for RADIUS or TACACS+ can be processed without a virtual access interface being created by a device.

To determine whether a virtual access interface is created, ensure the following exists:

- AAA per-user configuration

- Support for link interface support direct per-user AAA

not support direct per-user AAA (such as ISDN).

A virtual access interface is not created if the following conditions are not satisfied:

- There is no AAA per-user configuration.

- There is AAA per-user configuration and the link interface does support direct per-user AAA (such as asynchronous).

How to Configure a Virtual Interface Template

This section contains the following tasks:

- Creating and Configuring a Virtual Interface Template (required)

- Monitoring and Maintaining a Virtual Access Interface (required)

Note The order in which you create virtual interface template service and configure the features that use the templates and profiles is not important. They must exist, however, before someone calling in can use them.

Creating and Configuring a Virtual Interface Template

command.

Note Configuring the ip address command within a virtual interface template service is not recommended. Configuring a specific IP address in a virtual interface template can result in the establishment of erroneous routes and the loss of IP packets.

command.

commands.

For virtual interface template examples, see the “Configuration Examples for Virtual Interface Template” section section.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Device# configure terminal

Enters global configuration mode.

Step 3

Device(config)# interface virtual-template 0/0

Creates a virtual interface template and enters interface configuration mode.

Step 4

number

ip unnumbered ethernet 0/0

Enables IP without assigning a specific IP address on the LAN.

Step 5

encapsulation ppp

Enables PPP encapsulation on the virtual interface template.

Step 6

Device(config-if)# end

Exits interface configuration mode and returns to privileged EXEC mode.

Monitoring and Maintaining a Virtual Access Interface

When a virtual interface template or a configuration from a user on a AAA server or both are applied dynamically, a virtual access interface is created. Although a virtual access interface cannot be created and configured directly, it can be displayed and cleared.

commands.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Device# show interfaces virtual-access 3

Displays the configuration of the virtual access interface.

Step 3

Device# clear interface virtual-access 3

Tears down the virtual access interface and frees the memory for other dial-in uses.

Configuration Examples for Virtual Interface Template

The following sections provide virtual interface template configuration examples:

- Virtual Interface Template: Example

- Selective Virtual Access Interface: Example

- Selective Virtual Access Interface Configuration for RADIUS per User: Example

- Selective Virtual Access Interface Configuration for TACACS+ per User: Example

Virtual Interface Template: Example

The following example shows how to verify a virtual interface template configuration.

Note Effective with Cisco Release 12.4(11)T, the l2f protocol command was removed in Cisco IOS software.

Device# show interfaces virtual-access 1

Virtual-Access1 is a L2F link interface

interface Virtual-Access1 configuration...

ip unnumbered ethernet0

ipx ppp-client Loopback2

no cdp enable

ppp authentication chap

Selective Virtual Access Interface: Example

The following example shows how to create a virtual access interface for incoming calls that require a virtual access interface:

aaa new-model

aaa authentication ppp default local radius tacacs

aaa authorization network default local radius tacacs

virtual-profile if-needed

virtual-profile virtual-template 1

virtual-profile aaa

!

interface virtual-template 1

ip unnumbered Ethernet 0

no ip directed-broadcast

no keepalive

ppp authentication chap

ppp multilink

Selective Virtual Access Interface Configuration for RADIUS per User: Example

This example shows how to create AAA per-user configuration for a RADIUS user profile. When a AAA per-user configuration for a RADIUS user profile exists, a virtual access interface is configured automatically.

RADIUS user profile:

name1 Password = "test"

User-Service-Type = Framed-User,

Framed-Protocol = PPP,

cisco-avpair = "ip:inacl#1=deny 10.10.10.10 0.0.0.0",

cisco-avpair = "ip:inacl#1=permit any"

Selective Virtual Access Interface Configuration for TACACS+ per User: Example

This example shows how to create AAA per-user configuration for a TACACS+ user profile:

user = name1 {

name = "name1"

global = cleartext test

service = PPP protocol= ip {

inacl#1="deny 10.10.10.10 0.0.0.0"

inacl#1="permit any"

}

}

Additional References

The following sections provide references related to the Virtual Interface Template Service feature.

Related Documents

Related Topic

Document Title

Dial interfaces, controllers and lines

Dial commands

Standards

Standard

Title

None

—

MIBs

MIB

MIBs Link

None

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

RFCs

RFC

Title

None

—

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

Feature Information for Virtual Interface Template

lists the release history for this feature.

Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.

. An account on Cisco.com is not required.

Note Table 1 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.

Table 1 Feature Information for Virtual Interface Templates

Feature Name

Releases

Feature Information

Virtual Interface Template Service

Cisco IOS XE 3S

Virtual interface template service can be configured independently of any physical interface and applied dynamically to create virtual access interfaces.

The following sections provide information about this feature:

- Information About Virtual Interface Template Service

- Creating and Configuring a Virtual Interface Template

- Monitoring and Maintaining a Virtual Access Interface

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001–2009 Cisco Systems, Inc. All rights reserved.

Multiclass Multilink PPP

Feature History

Release

Modification

12.2(13)T

This feature was introduced.

This document describes the Multiclass Multilink PPP feature in Cisco IOS Release 12.2(13)T. It includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Prerequisites

- Configuration Tasks

- Configuration Examples

- Command Reference

Feature Overview

Previous implementations of Cisco IOS Multilink PPP (MLP) include support for Link Fragmentation Interleaving (LFI). This feature allows the delivery of delay-sensitive packets, such as the packets of a Voice call, to be expedited by omitting the PPP Multilink Protocol header and sending the packets as raw PPP packets in between the fragments of larger data packets. This feature works well on bundles consisting of a single link. However, when the bundle contains multiple links there is no way to keep the interleaved packets in sequence with respect to each other.

The Multiclass Multilink PPP (MCMP) feature in Cisco IOS Release 12.2(13)T addresses the limitations of MLP LFI on bundles containing multiple links by introducing multiple data classes. Normal data traffic and delay-sensitive data traffic are divided into Class 0 and Class 1, respectively. Class 0 data traffic is subject to fragmentation just as regular multilink packets are. Class 1 data traffic can be interleaved but never fragmented. The next transmit sequence number, expected sequence number, unassigned fragment list, working packet, lost fragment timer, fast-switching mode, and all statistics are managed per class, rather than for the bundle as a whole.

Benefits

The Multiclass Multilink PPP feature in Cisco IOS Release 12.2(13)T allows rapid delivery of real-time data over a bundle containing multiple links without loss of sequencing.

Restrictions

command must be configured on each link that will be joining the bundle. Failure to configure this command could result in the peer refusing to allow mismatched links to join the bundle. The first link to join the bundle will determine whether MCMP is in effect for the bundle. Each subsequent link must negotiate the same MCMP parameters in order to join the bundle.

Because real-time traffic is encapsulated with multilink headers, the receiver will be required to buffer the packets when they arrive out of sequence. Therefore, the differential delay between the links must be small relative to the tolerable delay for such traffic. Otherwise, packets may be subject to additional delay while the receiver awaits the arrival of earlier sequence numbers sent over other links in the bundle.

The maximum number of links supported for an MCMP bundle is 64.

The Prefix Elision option specified in RFC 2686 is not supported.

Related Features and Technologies

- Multilink PPP

Related Documents

- Cisco IOS Dial Technologies Configuration Guide, Release 12.2

- Cisco IOS Dial Technologies Command Reference , Release 12.2

Supported Platforms

- Cisco 2600 series

- Cisco 3600 series

- Cisco 3700 series

- Cisco 7200 series

- Cisco AS5300

- Cisco AS5350

- Cisco AS5400

Determining Platform Support Through Cisco Feature Navigator

Cisco IOS software is packaged in feature sets that are supported on specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Cisco Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.

To access Cisco Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:

Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:

Availability of Cisco IOS Software Images

Platform support for particular Cisco IOS software releases is dependent on the availability of the software images for those platforms. Software images for some platforms may be deferred, delayed, or changed without prior notice. For updated information about platform support and availability of software images for each Cisco IOS software release, refer to the online release notes or, if supported, Cisco Feature Navigator.

Supported Standards, MIBs, and RFCs

Standards

None

MIBs

None

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

If Cisco MIB Locator does not support the MIB information that you need, you can also obtain a list of supported MIBs and download MIBs from the Cisco MIBs page at the following URL:

To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:

RFCs

- RFC 2686, The Multi-Class Extension to Multi-Link PPP

Prerequisites

Release 12.2.

MLP LFI must be configured on the bundle. See the section “Configuring MLP LFI on a Bundle” in this document.

Configuration Tasks

See the following sections for configuration tasks for the Multiclass Multilink PPP feature. Each task in the list is identified as either required or optional.

- Configuring MLP LFI on a Bundle (required)

- Configuring MCMP on a Member Link (required)

- Verifying MCMP (optional)

Configuring MLP LFI on a Bundle

To configure MLP LFI on a dialer, multilink, or virtual template, use the following commands beginning in interface configuration mode:

Command

Purpose

Step 1

Enables MLP.

Step 2

Enables interleaving of packets among the fragments of larger packets on an MLP bundle.

Step 3

Specifies a maximum size, in units of time, for packet fragments on an MLP bundle.

Step 4

]

Reserves a special queue for real-time packet flows to specified destination User Datagram Protocol (UDP) ports, allowing real-time traffic to have higher priority than other flows.

Step 5

Exits interface configuration mode.

Step 6

For virtual templates only, applies the virtual template to the multilink bundle.1

1.This step is not used for dialer interfaces.

1.This step is not used for dialer interfaces.

Configuring MCMP on a Member Link

To configure MCMP on a configured and operational member link, use the following commands in interface configuration mode:

Command

Purpose

Step 1

Enables MLP.

Step 2

Enables MCMP on an interface.

Verifying MCMP

EXEC command. The following output includes class-specific information for the PPP Multilink bundles:

Router# show ppp multilink

Virtual-Access3, bundle name is bundle1

Bundle up for 01:59:35, 1/255 load, 2 receive classes, 2 transmit classes

Receive buffer limit 12192 bytes per class, frag timeout 1524 ms

Dialer interface is Dialer1

!

Receive Class 0:

0/0 fragments/bytes in reassembly list

0 lost fragments, 0 reordered

0/0 discarded fragments/bytes, 0 lost received

0x0 received sequence

!

Receive Class 1:

0/0 fragments/bytes in reassembly list

0 lost fragments, 0 reordered

0/0 discarded fragments/bytes, 0 lost received

0x0 received sequence

!

Transmit Class 0:

0x8 sent sequence

!

Transmit Class 1:

0x0 sent sequence

!

Member links: 1 (max not set, min not set)

BR2/0:1, since 01:59:35, 80 weight, 72 frag size

Configuration Examples

This section provides the following configuration example:

- Configuring MCMP on a Dialer Example

- MCMP and MLP Interleaving and Queueing for Real-Time Traffic Examples

Configuring MCMP on a Dialer Example

The following partial example configures a dialer for MCMP; it does not show the configuration of the physical interfaces:

interface Dialer0

ip address 10.0.0.2 255.0.0.0

encapsulation ppp

dialer in-band

dialer idle-timeout 500

dialer map ip 10.0.0.1 name remote broadcast 81012345678901

dialer load-threshold 30 either

dialer-group 1

ppp authentication chap

ppp multilink

ppp multilink multiclass

MCMP and MLP Interleaving and Queueing for Real-Time Traffic Examples

The following example enables MLP interleaving and MCMP on a dialer interface that controls a rotary group of BRI interfaces. This configuration permits IP packets to trigger calls.

interface BRI 0

description connected into a rotary group

encapsulation ppp

dialer rotary-group 1

!

interface BRI 1

no ip address

encapsulation ppp

dialer rotary-group 1

!

interface BRI 2

encapsulation ppp

dialer rotary-group 1

!

interface BRI 3

no ip address

encapsulation ppp

dialer rotary-group 1

!

interface BRI 4

encapsulation ppp

dialer rotary-group 1

!

interface Dialer 0

description Dialer group controlling the BRIs

ip address 10.1.1.1 255.255.255.0

encapsulation ppp

dialer map ip 10.1.1.2 name remote 14802616900

dialer-group 1

ppp authentication chap

! Enables Multilink Multiclass PPP interleaving on the dialer interface and reserves

! a special queue.

ppp multilink

ppp multilink multiclass

ppp multilink interleave

ip rtp reserve 32768 20 1000

! Keeps fragments of large packets small enough to ensure delay of 20 ms or less.

ppp multilink fragment delay 20

dialer-list 1 protocol ip permit

The following example defines a virtual interface template that enables MLP interleaving and a maximum real-time traffic delay of 20 milliseconds. The bundle interface will be a virtual access interface cloned from the virtual template. MCMP is then configured on a member link, Serial0.

interface virtual-template 1

ip unnumbered ethernet 0

ppp multilink

ppp multilink interleave

ppp multilink fragment delay 20

ip rtp interleave 32768 20 1000

!

multilink virtual-template 1

!

interface Serial0

encapsulation ppp

ppp authentication chap

ppp multilink

ppp multilink multiclass

The following example configures MLP interleaving and a maximum real-time traffic delay of 20 milliseconds on a multilink interface. MCMP is then configured on a member link, Serial1, and the member link is restricted to joining only the designated multilink group interface.

interface Multilink1

ip address 10.2.3.4 255.255.255.0

ppp multilink

ppp multilink interleave

ppp multilink fragment delay 20

!

interface Serial1

encapsulation ppp

ppp authentication chap

ppp multilink

ppp multilink multiclass

ppp multilink group 1

Command Reference

.

- ppp multilink multiclass

- show ppp multilin

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2008–2009 Cisco Systems, Inc. All rights reserved.

Configuring Asynchronous Callback

This chapter describes how to configure Cisco IOS software to call back an asynchronous device that dials in, requests a callback from the router, and then disconnects. It includes the following main sections:

- Asynchronous Callback Overview

- How to Configure Asynchronous Callback

- Configuration Examples for Asynchronous Callback

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

Asynchronous Callback Overview

Asynchronous callback is supported for the PPP and AppleTalk Remote Access (ARA) protocols. Callback is also supported on other interface types for PPP, including ISDN and any device that calls in and connects to the router at the EXEC level.

command on the callback lines.

All current security mechanisms supported in Cisco IOS software are supported by the callback facility, including the following:

- TACACS+

- Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP) for PPP

- Per-user authentication for EXEC callback and ARA callback

The call originator must have the appropriate permissions set on the router before it can initiate a callback session.

Callback is useful for two purposes:

- Cost savings on toll calls

For example, suppose it costs more to call from clients in Zone A to devices in Zone D than to call from Zone D to Zone A—costs are lower when devices in Zone D call back clients in Zone A.

- Consolidation and centralization of phone billing

For example, if a corporation has 64 dial-in clients, enabling its routers to call back these clients consolidates billing. Instead of 64 phone bills, the corporation receives one bill.

How to Configure Asynchronous Callback

To configure asynchronous callback, perform the tasks in the following sections:

- Configuring Callback PPP Clients (Required)

- Enabling PPP Callback on Outgoing Lines (Required)

- Enabling Callback Clients That Dial In and Connect to the EXEC Prompt (Required)

- Configuring Callback ARA Clients (Required)

See the section “Configuration Examples for Asynchronous Callback” at the end of this chapter for ideas on how to implement asynchronous callback.

Configuring Callback PPP Clients

You can call back PPP clients that dial in to asynchronous interfaces. You can enable callback to the following two types of PPP clients:

- Clients that implement PPP callback per RFC 1570 (as an link control protocol, or LCP, negotiated extension).

- Clients that do not negotiate callback but can put themselves in answer-mode, whereby a callback from the router is accepted.

This section describes how to enable callback to each of these types of PPP clients.

Accepting Callback Requests from RFC-Compliant PPP Clients

To accept a callback request from an RFC 1570 PPP-compliant client, use the following command in interface (asynchronous) configuration mode:

Command

Purpose

Enables callback requests from RFC 1570 PPP-compliant clients on an asynchronous interface.

To configure Cisco IOS software to call back the originating PPP client, see the section “Enabling PPP Callback on Outgoing Lines” later in this chapter.

Accepting Callback Requests from Non-RFC-Compliant PPP Clients Placing Themselves in Answer Mode

A PPP client can put itself in answer-mode and can still be called back by the router, even though it cannot specifically request callback. To enable callback on the router to this type of client, use the following command in interface (asynchronous) configuration mode:

Command

Purpose

Initiates callback requests from non-RFC 1570 PPP-compliant clients on an asynchronous interface.

To configure Cisco IOS software to call back the originating PPP client, see the next section, “Enabling PPP Callback on Outgoing Lines.”

Enabling PPP Callback on Outgoing Lines

After enabling PPP clients to connect to an asynchronous interface and wait for a callback, you must place one or more TTY lines in PPP mode. Although calls from PPP clients enter through an asynchronous interface, the calls exit the client on a line placed in PPP mode.

To enable PPP client callback on outgoing TTY lines, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Defines a chat script to be applied when a PPP client requests callback.

Step 2

]

Specifies a per-username callback dial string.

Step 3

]

Specifies a per-username rotary group for callback.

Step 4

]]

Specifies a per-username line or set of lines for callback.

Step 5

]

Enters line configuration mode.

Step 6

Configures automatic PPP startup on a line or set of lines.

Step 7

}

Enables authentication on the line.

Step 8

Applies a chat script to a line or set of lines.

Step 9

Delays the callback for client modems that require a rest period before receiving a callback.

if the dial string on the router is specified as NULL or is not defined. The recommended PPP chat script follows:

chat-script name ABORT ERROR ABORT BUSY ““ “ATZ” OK “ATDT \T” TIMEOUT 30 CONNECT \c

See the section “Callback to a PPP Client Example” at the end of this chapter for a configuration example.

Note Normally a router avoids line and modem noise by clearing the initial data received within the first one or two seconds. However, when the autoselect PPP feature is configured, the router flushes characters initially received and then waits for more traffic. This flush causes time out problems with applications that send only one carriage return. To ensure that the input data sent by a modem or other asynchronous device is not lost after line activation, enter the no flush-at-activation line configuration command.

Enabling Callback Clients That Dial In and Connect to the EXEC Prompt

You can call back clients that dial in to a TTY line and connect to the EXEC prompt. To enable callback, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Enables EXEC callback.

Step 2

Defines a chat script to be applied when clients dial in to the EXEC prompt.

Step 3

]

Specifies a per-username callback dial string.

Step 4

]

Specifies a per-username rotary group for callback.

Step 5

]]

Specifies a per-username line or set of lines for callback.

Step 6

]

Does not require authentication on EXEC callback.

Step 7

]

Enters line configuration mode.

Step 8

Applies a chat script to the line or a set of lines.

Step 9

Delays the callback for client modems that require a rest period before receiving a callback.

The recommended EXEC chat script follows:

chat-script name ABORT ERROR ABORT BUSY ““ “ATZ” OK “ATDT \T” TIMEOUT 30 CONNECT \c

See the section “Callback Clients That Connect to the EXEC Prompt Example” at the end of this chapter for a configuration example.

Configuring Callback ARA Clients

To configure callback of ARA clients, use the following commands beginning in global configuration mode. These steps assume that you have already enabled AppleTalk routing and ARA.

Command

Purpose

Step 1

Enables callback to an ARA client.

Step 2

Defines a chat script to be applied when an ARA client connects to a TTY line and requests callback.

Step 3

]

Enters line configuration mode.

Step 4

Enables ARA on the line.

Step 5

Configures automatic protocol startup on the line.

Step 6

}

Enables authentication on the line.

Step 7

Applies an ARA-specific chat script to a line or set of lines.

Step 8

Delays the callback for client modems that require a rest period before receiving a callback.

Step 9

Returns to global configuration mode.

Step 10

]

Specifies a per-username callback dial string.

Step 11

]

Specifies a per-username rotary group for callback.

Step 12

]]

Specifies a per-username line or set of lines for callback.

The recommended ARA chat script follows and includes vendor-specific extensions on the Telebit 3000 modem to disable error control. Refer to the manual for your modem for the specific commands to disable error correction for ARA.

chat-script name ABORT ERROR ABORT BUSY ““ “ATZ” OK “ATS180=0” OK “ATS181=1” OK “ATDT \T” TIMEOUT 60 CONNECT \c

See the section “Callback to an ARA Client Example” at the end of this chapter for an example of calling back a PPP client.

Configuration Examples for Asynchronous Callback

The following sections provide asynchronous callback configuration examples:

- Callback to a PPP Client Example

- Callback Clients That Connect to the EXEC Prompt Example

- Callback to an ARA Client Example

Callback to a PPP Client Example

command enables local username authentication on lines 7, 8, and 9. The remote PPP client host name is Ted, and the callback number is fixed at 1234567.

username Ted callback-dialstring “1234567“ callback-rotary 77

password Rhoda

interface async 7

ip unnumbered ethernet 0

encapsulation ppp

no keepalive

async default ip address 10.1.1.1

async mode interactive

ppp callback accept

ppp authentication pap

interface async 8

ip unnumbered ethernet 0

encapsulation ppp

no keepalive

async default ip address 10.1.1.2

async mode interactive

ppp callback accept

ppp authentication pap

interface async 9

ip unnumbered ethernet 0

encapsulation ppp

no keepalive

async default ip address 10.1.1.3

async mode interactive

ppp callback accept

ppp authentication pap

line 7

login local

modem InOut

rotary 77

autoselect ppp

line 8

login local

modem InOut

rotary 77

autoselect ppp

line 9

login local

modem InOut

rotary 77

autoselect ppp

Callback Clients That Connect to the EXEC Prompt Example

command enables local username authentication on lines 4 and 7. Reauthentication is required upon reconnection.

service exec-callback

username milarepa callback-dialstring ““ password letmein

line 4

login local

line 7

login local

Callback to an ARA Client Example

command enables local username authentication on lines 4 and 7. Line 7 will always be used for ARA callback, whether the incoming call enters line 4, 7, or 8.

appletalk routing

arap callback

arap network 422 router test

username excalibur callback-dialstring “123456“ callback-line 7 password guenivere

line 4

login local

modem InOut

autoselect arap

arap enable

line 7

login local

modem InOut

autoselect arap

arap enable

line 8

login local

modem InOut

autoselect arap

arap enable

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001–2009 Cisco Systems, Inc. All rights reserved.

Configuring PPP Callback

This chapter describes how to configure PPP callback for dial-on-demand routing (DDR). It includes the following main sections:

- PPP Callback for DDR Overview

- How to Configure PPP Callback for DDR

- MS Callback Overview

- How to Configure MS Callback

- Configuration Examples for PPP Callback

This feature implements the following callback specifications of RFC 1570:

- For the client—Option 0, location is determined by user authentication.

- For the server—Option 0, location is determined by user authentication; Option 1, dialing string; and Option 3, E.164 number.

Return calls are made through the same dialer rotary group but not necessarily the same line as the initial call.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

PPP Callback for DDR Overview

PPP callback provides a client/server relationship between the endpoints of a point-to-point connection. PPP callback allows a router to request that a dialup peer router call back. The callback feature can be used to control access and toll costs between the routers.

When PPP callback is configured on the participating routers, the calling router (the callback client) passes authentication information to the remote router (the callback server), which uses the host name and dial string authentication information to determine whether to place a return call. If the authentication is successful, the callback server disconnects and then places a return call. The remote username of the return call is used to associate it with the initial call so that packets can be sent.

Both routers on a point-to-point link must be configured for PPP callback; one must function as a callback client and one must be configured as a callback server. The callback client must be configured to initiate PPP callback requests, and the callback server must be configured to accept PPP callback requests and place return calls.

See the section “MS Callback Overview” later in this chapter if you are using PPP callback between a Cisco router or access server and client devices configured for Windows 95 and Windows NT.

Note If the return call fails (because the line is not answered or the line is busy), no retry occurs. If the callback server has no interface available when attempting the return call, it does not retry.

How to Configure PPP Callback for DDR

To configure PPP callback for DDR, perform the following tasks:

- Configuring a Router As a Callback Client (Required)

- Configuring a Router As a Callback Server (Required)

For an example of configuring PPP callback, see the section “Configuration Examples for PPP Callback” at the end of this chapter.

Configuring a Router As a Callback Client

To configure a router interface as a callback client, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Specifies the interface and enters interface configuration mode.

Step 2

]

Enables DDR. Specifies parity, if needed, on synchronous or asynchronous serial interfaces.

Step 3

Enables PPP encapsulation.

Step 4

}

Enables CHAP or PAP authentication.

Step 5

Maps the next hop address to the host name and phone number.

Step 6

Enables the interface to request PPP callback for this callback map class.

Step 7

(Optional) Configures a dialer hold queue to store packets for this callback map class.

Configuring a Router As a Callback Server

To configure a router as a callback server, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Specifies the interface and enters interface configuration mode.

Step 2

]

Enables DDR. Specifies parity, if needed, on synchronous or asynchronous serial interfaces.

Step 3

Enables PPP encapsulation.

Step 4

}

Enables CHAP or PAP authentication.

Step 5

Maps the next hop address to the host name and phone number, using the name of the map class established for PPP callback on this interface.

Step 6

(Optional) Configures a dialer hold queue to store packets to be transferred when the callback connection is established.

Step 7

(Optional) Configures a timeout period between calls.

Step 8

Configures the interface to accept PPP callback.

Step 9

(ISDN only) Configures the time to wait before another call is placed on a B channel to allow the prior call to be torn down completely.

Step 10

(Optional) Enables callback security, if desired.

Step 11

Returns to global configuration mode.

Step 12

Configures a dialer map class for PPP callback.

Step 13

]

Configures a dialer map class as a callback server.

Note On the PPP callback server, the dialer enable-timeout command functions as the timer for returning calls to the callback client.

MS Callback Overview

MS Callback provides client/server callback services for Microsoft Windows 95 and Microsoft Windows NT clients. MS Callback supports the Microsoft Callback Control Protocol (MSCB). MSCB is a Microsoft proprietary protocol that is used by Windows 95 and Windows NT clients. MS Callback supports negotiated PPP Link Control Protocol (LCP) extensions initiated and agreed upon by the Microsoft client. The MS Callback feature is added to existing PPP Callback functionality. Therefore, if you configure your Cisco access server to perform PPP Callback using Cisco IOS Release 11.3(2)T or later, MS Callback is automatically available.

MS Callback supports authentication, authorization, and accounting (AAA) security models using a local database or AAA server.

MSCB uses LCP callback options with suboption type 6. The Cisco MS Callback feature supports clients with a user-specified callback number and server specified (preconfigured) callback number.

MS Callback does not affect non-Microsoft machines that implement standard PPP LCP extensions as described in RFC 1570. In this scenario, MS Callback is transparent.

The following are restrictions of the MS Callback feature:

- The Cisco access server and client must be configured for PPP and PPP callback.

- The router or access server must be configured to use CHAP or PAP authorization.

- MS Callback is only supported on the Public Switched Telephone Network (PSTN) and ISDN links.

- MS Callback is only supported for IP.

How to Configure MS Callback

publication.

Configuration Examples for PPP Callback

The following example configures a PPP callback server and client to call each other. The PPP callback server is configured on an ISDN BRI interface in a router in Atlanta. The callback server requires an enable timeout and a map class to be defined. The PPP callback client is configured on an ISDN BRI interface in a router in Dallas. The callback client does not require an enable timeout and a map class to be defined.

PPP Callback Server

interface bri 0

ip address 10.1.1.7 255.255.255.0

encapsulation ppp

dialer callback-secure

dialer enable-timeout 2

dialer map ip 10.1.1.8 name atlanta class dial1 81012345678901

dialer-group 1

ppp callback accept

ppp authentication chap

!

map-class dialer dial1

dialer callback-server username

PPP Callback Client

interface bri 0

ip address 10.1.1.8 255.255.255.0

encapsulation ppp

dialer map ip 10.1.1.7 name dallas 81012345678902

dialer-group 1

ppp callback request

ppp authentication chap

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007-2008 Cisco Systems, Inc. All rights reserved.

Configuring ISDN Caller ID Callback

This chapter describes how to configure the ISDN Caller ID Callback feature. It includes the following main sections:

- ISDN Caller ID Callback Overview

- How to Configure ISDN Caller ID Callback

- Monitoring and Troubleshooting ISDN Caller ID Callback

- Configuration Examples for ISDN Caller ID Callback

The ISDN Caller ID Callback feature conflicts with dialer callback security inherent in the dialer profiles feature for dial-on-demand routing (DDR). If dialer callback security is configured, it takes precedence; ISDN caller ID callback is ignored.

Caller ID screening requires a local switch that is capable of delivering the caller ID to the router or access server. If you enable caller ID screening but do not have such a switch, no calls will be allowed in.

ISDN caller ID callback requires DDR to be configured and bidirectional dialing to be working between the calling and callback routers. Detailed DDR prerequisites depend on whether you have configured legacy DDR or dialer profiles.

For a legacy DDR configuration, ISDN caller ID callback has the following prerequisite:

- A dialer map command is configured for the dial string that is used in the incoming call setup message. The dial string is used in the callback.

For a dialer profiles configuration, ISDN caller ID callback has the following prerequisites:

- A dialer caller command is configured to screen for the dial-in number.

- A dialer string command is configured with the number to use in the callback.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

, Release 12.2. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

ISDN Caller ID Callback Overview

ISDN caller ID callback allows the initial incoming call from the client to the server to be rejected on the basis of the caller ID message contained in the ISDN setup message, and it allows a callback to be initiated to the calling destination.

Before Cisco IOS Release 11.2 F, ISDN callback functionality required PPP or Combinet Packet Protocol (CPP) client authentication and client/server callback negotiation to proceed. If authentication and callback negotiation were successful, the callback server had to disconnect the call and then place a return call. Both the initial call and the return call were subject to tolls, and when service providers charge by the minute, even brief calls could be expensive.

This feature is independent of the encapsulation in effect and can be used with various encapsulations, such as PPP, High-Level Data Link Control (HDLC), Frame Relay, and X.25.

The ISDN Caller ID Callback feature allows users to control costs because charges do not apply to the initial, rejected call.

ISDN caller ID callback allows great flexibility for you to define which calls to accept, which to deny, and which calls to reject initially but for which the router should initiate callback. The feature works by using existing ISDN caller ID screening, which matches the number in the incoming call against numbers configured on the router, determining the best match for the number in the incoming call, and then, if configured, initiating callback to the number configured on the router.

When a call is received, the entire list of configured numbers is checked and the configuration of the best match number determines the action:

- If the incoming number is best matched by a number that is configured for callback, the incoming call is rejected and callback is initiated.

- If the incoming number is best matched by another entry in the list of configured numbers, the call is accepted.

- If the incoming number does not match any entry in the configured list, the call is rejected and no callback is started.

“Don’t care” characters are allowed in the caller ID screening configuration on the router and are used to determine the best match.

For more information and examples, see the “Best Match System Examples” section later in this document.

Callback After the Best Match Is Determined

The details of router activities after the router finds a best match with callback depend on the DDR feature that is configured. The ISDN Caller ID Callback feature works with the following DDR features:

- Legacy DDR

- Dialer Profiles

Legacy DDR

If legacy DDR is configured for the host or user that is identified in the incoming call message, the router performs the following actions:

1. Checks the table of configured numbers for caller ID callback.

entries for a number that “best matches” the incoming call string.

3. Waits for a configured length of time to expire.

command.

Dialer Profiles

If the dialer profiles are configured for the host or user identified in the incoming call message, the router performs the following actions:

number.

2. Initiates a callback to the dialer profile.

3. Waits for a configured length of time to expire.

command associated with the dialer profile.

Timing and Coordinating Callback on Both Sides

command to determine the length of time to wait before making the callback.

command) on the calling (remote) side. We recommend setting the dialer wait-for-carrier timer on the calling side to twice the length of the dialer enable-timeout timer on the callback side.

Note The remote site cannot be configured for multiple dial-in numbers because a busy callback number or a rejected call causes the second number to be tried. That number might be located at a different site, defeating the purpose of the callback.

How to Configure ISDN Caller ID Callback

To configure ISDN caller ID callback, perform the tasks in the following sections. The required configuration tasks depend whether you have configured legacy DDR or dialer profiles.

- Configuring ISDN Caller ID Callback for Legacy DDR (As required)

- Configuring ISDN Caller ID Callback for Dialer Profiles (As required)

For configuration examples, see the section “Configuration Examples for ISDN Caller ID Callback” at the end of this chapter.

Configuring ISDN Caller ID Callback for Legacy DDR

This section provides configuration tasks for the local (server, callback) side and the remote (client, calling) side.

On the callback (local) side, to configure ISDN caller ID callback when legacy DDR is configured, use the following commands in interface configuration mode:

Command

Purpose

Step 1

or

Configures caller ID screening and callback when a dialer rotary is not configured.

Configures caller ID screening and callback when a dialer rotary (dialer interface) is configured.

Step 2

Configures the time to wait before initiating callback.

On the calling (remote) side, to set the timer for fast call rerouting, use the following command in interface configuration mode:

Command

Purpose

Changes the ISDN fast call rerouting timer to double the length of the enable timeout timer.

Configuring ISDN Caller ID Callback for Dialer Profiles

This section provides configuration tasks for the local side and the remote side.

On the callback (local) side, to configure ISDN caller ID callback when the dialer profiles are configured, use the following commands in interface configuration mode:

Command

Purpose

Step 1

Configures caller ID screening and callback.

Step 2

Configures the time to wait before initiating callback.

On the calling (remote) side, to set the timer for fast call rerouting, use the following command in interface configuration mode:

Command

Purpose

Changes the ISDN fast call rerouting timer to double the length of the enable timeout timer.

Monitoring and Troubleshooting ISDN Caller ID Callback

To monitor and troubleshoot ISDN caller ID callback, use the following commands in EXEC mode as needed:

Command

Purpose

Displays information about the status and configuration of the ISDN interface on the router.

Displays ISDN events occurring on the user side (on the router) of the ISDN interface. The ISDN events that can be displayed are Q.931 events (call setup and tear down of ISDN network connections).

Displays Layer 3 signaling messages, protocol transitions and processes, the line protocol state, and the channel IDs for each ISDN interface.

Configuration Examples for ISDN Caller ID Callback

The following sections provide ISDN caller ID callback configuration examples:

- Best Match System Examples

- Simple Callback Configuration Examples

- ISDN Caller ID Callback with Dialer Profiles Examples

- ISDN Caller ID Callback with Legacy DDR Example

Best Match System Examples

The best match is determined by matching the incoming number against the numbers in the configured callback commands, starting with the right-most character in the numbers and using the letter X for any “don’t care” characters in the configured commands. If multiple configured numbers match an incoming number, the best match is the one with the fewest “don’t care” characters.

The reason for using a system based on right-most matching is that a given number can be represented in many different ways. For example, all the following items might be used to represent the same number, depending on the circumstances (international call, long-distance domestic call, call through a PBX, and so forth):

011 1 408 555 7654

1 408 555 7654

408 555 7654

555 7654

5 7654

Best Match Based on the Number of “Don’t Care” Characters Example

The following example assumes that you have an incoming call from one of the numbers from the previous example entered (4085557654), and that you configured the following numbers for callback on the router (disregarding for the moment the commands that can be used to configure callback):

555xxxx callback

5552xxx callback

555865x

5554654 callback

xxxxx

The first number listed is the best match for the incoming number (in the configured number, the three numbers and four Xs all match the incoming number); the line indicates that callback is to be initiated. The last line has five Xs; it is not the best match for the calling number.

Note The last number in the list shown allows calls from any other number to be accepted without callback. When you use such a line, you must make sure that the number of Xs in the line exceeds the number of Xs in any other line. In the last line, five Xs are used; the other lines use at most four Xs.

The order of configured numbers is not important; the router searches the entire list and then determines the best match.

Best Match with No Callback Configured Example

The following example assumes that a call comes from the same number (4085557654) and that only the following numbers are configured:

5552xxx callback

555865x

5554654 callback

xxxxx

In this case, the best match is in the final line listed, so the incoming call is accepted but callback is not initiated.

No Match Configured Example

The following example assumes that a call comes from the same number (4085557654) and that only the following numbers are configured:

5552xxx callback

555865x

5554654 callback

In this case, there is no match at all, and the call is just rejected.

Simple Callback Configuration Examples

The following example assumes that callback calls will be made only to numbers in the 555 and 556 exchanges but that any other number can call in:

isdn caller 408555xxxx callback

isdn caller 408556xxxx callback

isdn caller xxxxx

The following example configures the router to accept a call with a delivered caller ID equal to 4155551234:

isdn caller 4155551234

The following example configures the router to accept a call with a delivered caller ID equal to 41555512 with any digits in the last two positions:

isdn caller 41555512xx

The following example configures the router to make a callback to a delivered caller ID equal to 41555512 with any digits in the last two positions. (The router rejects the call initially, and then makes the callback.) The router accepts calls from any other numbers.

isdn caller 41555512xx callback

isdn caller xxx

ISDN Caller ID Callback with Dialer Profiles Examples

The following example shows the configuration of a central site that can place or receive calls from three remote sites over four ISDN BRI lines. Each remote site is on a different IP subnet and has different bandwidth requirements. Therefore, three dialer interfaces and three dialer pools are defined.

! This is a dialer profile for reaching remote subnetwork 10.1.1.1.

interface dialer 1

ip address 10.1.1.1 255.255.255.0

encapsulation ppp

dialer remote-name Smalluser

dialer string 4540

dialer pool 3

dialer-group 1

dialer caller 14802616900 callback

dialer caller 1480262xxxx callback

!

! This is a dialer profile for reaching remote subnetwork 10.2.2.2.

interface dialer 2

ip address 10.2.2.2 255.255.255.0

encapsulation ppp

dialer remote-name Mediumuser

dialer string 5264540 class Eng

dialer load-threshold 50 either

dialer pool 1

dialer-group 2

dialer caller 14805364540 callback

dialer caller 1480267xxxx callback

dialer enable-timeout 2

!

! This is a dialer profile for reaching remote subnetwork 10.3.3.3.

interface dialer 3

ip address 10.3.3.3 255.255.255.0

encapsulation ppp

dialer remote-name Poweruser

dialer string 4156884540 class Eng

dialer hold-queue 10

dialer load-threshold 80

dialer pool 2

dialer-group 2

!

! This map class ensures that these calls use an ISDN speed of 56 kbps.

map-class dialer Eng

isdn speed 56

!

interface bri 0

encapsulation PPP

! BRI 0 has a higher priority than BRI 1 in dialer pool 1.

dialer pool-member 1 priority 100

ppp authentication chap

!

interface bri 1

encapsulation ppp

dialer pool-member 1 priority 50

dialer pool-member 2 priority 50

! BRI 1 has a reserved channel in dialer pool 3; the channel remains inactive

! until BRI 1 uses it to place calls.

dialer pool-member 3 min-link 1

ppp authentication chap

!

interface bri 2

encapsulation ppp

! BRI 2 has a higher priority than BRI 1 in dialer pool 2.

dialer pool-member 2 priority 100

ppp authentication chap

!

interface bri 3

encapsulation ppp

! BRI 3 has the highest priority in dialer pool 2.

dialer pool-member 2 priority 150

ppp authentication chap

ISDN Caller ID Callback with Legacy DDR Example

This section provides two examples of caller ID callback with legacy DDR:

- Individual Interface Example

- Dialer Rotary Group Example

Individual Interface Example

The following example configures a BRI interface for legacy DDR and ISDN caller ID callback:

interface bri 0

description Connected to NTT 81012345678901

ip address 10.1.1.7 255.255.255.0

no ip mroute-cache

encapsulation ppp

isdn caller 81012345678902 callback

dialer enable-timeout 2

dialer map ip 10.1.1.8 name spanky 81012345678902

dialer-group 1

ppp authentication chap

Dialer Rotary Group Example

The following example configures BRI interfaces to connect into a rotary group (dialer group) and then configures a dialer interface for that dialer group. This configuration permits IP packets to trigger calls. The dialer interface is configured to initiate callback to any number in the 1-480-261 exchange and to accept calls from two other specific numbers.

interface bri 0

description connected into a rotary group

encapsulation ppp

dialer rotary-group 1

!

interface bri 1

no ip address

encapsulation ppp

dialer rotary-group 1

!

interface bri 2

encapsulation ppp

dialer rotary-group 1

!

interface bri 3

no ip address

encapsulation ppp

dialer rotary-group 1

!

interface bri 4

encapsulation ppp

dialer rotary-group 1

!

interface dialer 0

description Dialer group controlling the BRIs

ip address 10.1.1.1 255.255.255.0

encapsulation ppp

dialer map ip 10.1.1.2 name angus 14802616900

dialer map ip 10.1.1.3 name shamus 14802616901

dialer map ip 10.1.1.4 name larry 14807362060

dialer map ip 10.1.1.5 name wally 19165561424

dialer map ip 10.1.1.6 name shemp 12129767448

dialer-group 1

ppp authentication chap

!

dialer caller 1480261xxxx callback

dialer caller 19165561424

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007–2009 Cisco Systems, Inc. All rights reserved.

Configuring BACP

This chapter describes how to configure the Bandwidth Allocation Control Protocol (BACP), described in RFC 2125. It includes the following main sections:

- BACP Overview

- How to Configure BACP

- Monitoring and Maintaining Interfaces Configured for BACP

- Troubleshooting BACP

- Configuration Examples for BACP

BACP requires a system only to have the knowledge of its own phone numbers and link types. A system must be able to provide the phone numbers and link type to its peer to satisfy the call control mechanism. (Certain situations might not be able to satisfy this requirement; numbers might not be present because of security considerations.)

BACP is designed to operate in both the virtual interface environment and the dialer interface environment. It can operate over any physical interface that is Multilink PPP-capable and has a dial capability; at initial release, BACP supports ISDN and asynchronous serial interfaces.

The addition of any link to an existing multilink bundle is controlled by a Bandwidth Allocation Protocol (BAP) call or callback request message, and the removal of a link can be controlled by a link drop message.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

, Release 12.2. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

BACP Overview

The BACP provides Multilink PPP (MLP) peers with the ability to govern link utilization. Once peers have successfully negotiated BACP, they can use the BAP, which is a subset of BACP, to negotiate bandwidth allocation. BAP provides a set of rules governing dynamic bandwidth allocation through call control; a defined method for adding and removing links from a multilink bundle for Multilink PPP is used.

BACP provides the following benefits:

- Allows multilink implementations to interoperate by providing call control through the use of link types, speeds, and telephone numbers.

- Controls thrashing caused by links being brought up and removed in a short period of time.

- Ensures that both ends of the link are informed when links are added or removed from a multilink bundle.

For simplicity, the remaining text of this chapter makes no distinction between BACP and BAP; only BACP is mentioned.

BACP Configuration Options

PPP BACP can be configured to operate in the following ways:

- Passive mode (default)—The system accepts incoming calls; the calls might request callback, addition of a link, or removal of a link from a multilink bundle. The system also monitors the multilink load by default.

Passive mode is for virtual template interfaces or for dialer interfaces.

- Active mode—The system initiates outbound calls, sets the parameters for outbound calls, and determines whether links should be added to or removed from a multilink bundle. The system also monitors the multilink load by default.

Active mode is for dialer interfaces, but not for virtual template interfaces. (If you attempt to configure active mode on a virtual template interface, no calls will be made.)

A virtual or dialer interface must be configured either to make call requests or to make callback requests, but it cannot be configured to do both.

Support of BACP on virtual interfaces in an Multichassis Multilink PPP (MMP) environment is restricted to incoming calls on the multilink group. Support of BACP for outgoing calls is provided by dialer interface configuration only.

BACP supports only ISDN and asynchronous serial interfaces.

Dialer support is provided only for legacy dial-on-demand routing (DDR) dialer configurations; BACP cannot be used in conjunction with the DDR dialer profiles feature.

BACP is configured on virtual template interfaces and physical interfaces that are multilink capable. For both the virtual template interfaces and the dialer interfaces, BACP requires MMP and bidirectional dialing to be working between the routers that will negotiate control and allocation of bandwidth for the multilink bundle.

How to Configure BACP

Before you configure BACP on an interface, determine the following important information. The router might be unable to connect to a peer if this information is incorrect.

- Type of link (ISDN or analog) to be used. Link types must match on the local and remote ends of the link.

- Line speed needed to reach the remote peer. The speed configured for the local physical interface must be at least that of the link. The bandwidth command or the dialer map command with the speed keyword can be used.

- Local telephone number to be used for incoming PPP BACP calls, if it is different from a rotary group base number or if incoming PPP BACP calls should be directed to a specific number.

, indicating that the peer should modify certain digits of the dialed phone number and dial again to reach the PPP BACP interface or to set up another link.

BACP can be configured on a virtual template interface or on a dialer interface (including dialer rotary groups and ISDN interfaces).

To configure BACP on a selected interface or interface template, perform the following tasks in the order listed:

- Enabling BACP (Required)

the passive mode parameters, do not continue with the tasks.

- Modifying BACP Passive Mode Default Settings (As required)

or

- Configuring Active Mode BACP (As required)

Note You can configure one interface in passive mode and another in active mode so that one interface accepts incoming call requests and makes callback requests (passive mode), and the other interface makes call requests and accepts callback requests (active mode).

A dialer or virtual template interface should be configured to reflect the required dial capability of the interface. A dial-in pool (in passive mode) might have no requirement to dial out but might want remote users to add multiple links, with the remote user incurring the cost of the call. Similarly, a dial-out configuration (active mode) suggests that the router is a client, rather than a server, on that link. The active-mode user incurs the cost of additional links.

command options in the task lists.

You can also troubleshoot BACP configuration and operations and monitor interfaces configured for PPP BACP. For details, see the “Troubleshooting BACP” and “Monitoring and Maintaining Interfaces Configured for BACP” sections later in this chapter.

See the section “Configuration Examples for BACP” at the end of this chapter for examples of PPP BACP configuration.

Enabling BACP

To enable PPP bandwidth allocation control and dynamic allocation of bandwidth, use one of the following commands in interface configuration mode:

Command

Purpose

Router(config-if)# ppp multilink bap

or

Enables PPP BACP bandwidth allocation negotiation.

Enables PPP BACP bandwidth allocation negotiation and enforces mandatory negotiation of BACP for the multilink bundle.

When PPP BACP is enabled, it is in passive mode by default and the following settings are in effect:

- Allows a peer to initiate link addition.

- Allows a peer to initiate link removal.

- Requests that a peer initiate link addition.

- Waits 20 seconds before timing out on pending actions.

- Waits 3 seconds before timing out on not receiving a response from a peer.

- Makes only one attempt to call a number.

- Makes up to three retries for sending a request.

- Searches for and logs up to five free dialers.

- Makes three attempts to send a call status indication.

- Adds only ISDN links to a multilink bundle.

- Monitors load.

command is entered:

- Virtual template interface, if that is where the command is entered.

When the command is entered in a virtual template interface, configuration applies to any virtual access interface that is created dynamically under Multilink PPP, the application that defines the template.

- Dialer interface, if that is where the command is entered.

See the section “Basic BACP Configurations” at the end of this chapter for an example of how to configure BACP.

Modifying BACP Passive Mode Default Settings

To modify the default parameter values or to configure additional parameters in passive mode, use the following commands, as needed, in interface configuration mode for the interface or virtual template interface that is configured for PPP BACP:

Command

Purpose

Modifies the timeout on pending actions.

Modifies the timeout on not receiving a response from a peer.

Modifies the number of attempts to call a number.

Modifies the number of times to send a call status indication.

Modifies the number of retries of a particular request.

Modifies the maximum number of free dialers logged.

or

Specifies that only analog links can be added to a multilink bundle.

Allows both ISDN and analog links to be added.

For all DDR-capable interfaces in the group, specifies a primary telephone number for the peer to call for PPP BACP negotiation, if different from any base number defined on the dialer interface or virtual template interface.

For BRI interfaces on which a different number is provided for each B channel, specifies the secondary telephone number.

Specifies a time to wait between outgoing link drop requests.

Disables the default monitoring of load and the validation of peer requests against load thresholds.

See the section “Passive Mode Dialer Rotary Group Members with One Dial-In Number” later in this chapter for an example of how to configure passive mode parameters.

Configuring Active Mode BACP

To configure active mode BACP, use the following commands in interface configuration mode for the dialer interface on which BACP was enabled. For your convenience, the commands that make BACP function in active mode are presented before the commands that change default parameters or add parameters.

Command

Purpose

Enables the interface to initiate the addition of links to the multilink bundle.

Enables the interface to initiate the addition of links upon peer request.

Enables the interface to drop a link without negotiation after receiving no response to retries to send a drop request.

Sets the time to wait between outgoing call requests.

Modifies the timeout on pending actions.

Modifies the timeout on not receiving a response from a peer.

Modifies the number of attempts to call a number.

Modifies the number of times to send a call status indication.

Modifies the number of retries of a particular request.

Modifies the maximum number of free dialers logged.

or

Specifies that only analog links can be added to a multilink bundle.

Allows both ISDN and analog links to be added.

For all DDR-capable interfaces in the group, specifies a primary telephone number for the peer to call for PPP BACP negotiation, if different from any base number defined on the dialer interface or virtual template interface.

For BRI interfaces on which a different number is provided for each B channel, specifies the secondary telephone number.

When BACP is enabled, multiple dialer maps to one destination are not needed when they differ only by number. That is, once the initial call has been made to create the bundle, further dialing attempts are realized through the BACP phone number negotiation.

command. These temporary dialer maps last only as long as the BACP group lasts and are removed when the BACP group or the associated map is removed.

Monitoring and Maintaining Interfaces Configured for BACP

To monitor interfaces configured for PPP BACP, use any of the following commands in EXEC mode:

Command

Purpose

]

Displays information about all PPP BACP multilink bundle groups or a specific, named multilink bundle group.

Displays information about the BACP queues.

Displays information about the dialer interface, the multilink bundle, and the group members.

Displays BACP numbers dialed and the reasons for the calls.

Displays configured dynamic and static dialer maps and dynamically created BACP temporary static dialer maps.

Troubleshooting BACP

commands:

Command

Purpose

]

Displays BACP errors, protocol actions, and negotiation events and transitions.

Displays information about events affecting multilink bundles established for BACP.

Configuration Examples for BACP

The following sections provide BACP configuration examples:

- Basic BACP Configurations

- Dialer Rotary Group with Different Dial-In Numbers

- Passive Mode Dialer Rotary Group Members with One Dial-In Number

- PRI Interface with No Defined PPP BACP Number

- BRI Interface with No Defined BACP Number

Basic BACP Configurations

The following example configures an ISDN BRI interface for BACP to make outgoing calls and prevent the peer from negotiating link drops:

interface bri 0

ip unnumbered ethernet 0

dialer load-threshold 10 either

dialer map ip 172.21.13.101 name bap-peer 12345668899

encapsulation ppp

ppp multilink bap

ppp bap call request

ppp bap callback accept

no ppp bap call accept

no ppp bap drop accept

ppp bap pending timeout 30

ppp bap number default 5664567

ppp bap number secondary 5664568

The following example configures a dialer rotary group to accept incoming calls:

interface async 1

no ip address

encapsulation ppp

dialer rotary-group 1

ppp bap number default 5663456

!

! Set the bandwidth to suit the modem/line speed on the remote side.

interface bri 0

no ip address

bandwidth 38400

encapsulation ppp

dialer rotary-group 1

ppp bap number default 5663457

!

interface bri 1

no ip address

encapsulation ppp

dialer rotary-group 1

ppp bap number default 5663458

!

interface dialer1

ip unnumbered ethernet 0

encapsulation ppp

ppp multilink bap

ppp bap call accept

ppp bap link types isdn analog

dialer load threshold 30

ppp bap timeout pending 60

The following example configures a virtual template interface to use BACP in passive mode:

multilink virtual-template 1

!

interface virtual-template 1

ip unnumbered ethernet 0

encapsulation ppp

ppp multilink bap

ppp authentication chap callin

The bundle is created from any MMP-capable interface.

The following example creates a bundle on a BRI interface:

interface bri 0

no ip address

encapsulation ppp

ppp multilink

ppp bap number default 4000

ppp bap number secondary 4001

Dialer Rotary Group with Different Dial-In Numbers

The following example configures a dialer rotary group that has four members, each with a different number, and that accepts incoming dial attempts. The dialer interface does not have a base phone number; the interface used to establish the first link in the multilink bundle will provide the appropriate number from its configuration.

interface bri 0

no ip address

encapsulation ppp

dialer rotary-group 1

no fair-queue

no cdp enable

ppp bap number default 6666666

!

interface bri 1

no ip address

encapsulation ppp

dialer rotary-group 1

no fair-queue

no cdp enable

ppp bap number default 6666667

!

interface bri 2

no ip address

encapsulation ppp

dialer rotary-group 1

no fair-queue

no cdp enable

ppp bap number default 6666668

!

interface bri 3

no ip address

encapsulation ppp

dialer rotary-group 1

no fair-queue

no cdp enable

ppp bap number default 6666669

!

interface dialer 1

ip unnumbered Ethernet0

encapsulation ppp

dialer in-band

dialer idle-timeout 300

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap

ppp multilink bap

ppp bap call accept

ppp bap callback request

ppp bap timeout pending 20

ppp bap timeout response 2

ppp bap max dial-attempts 2

ppp bap monitor load

Passive Mode Dialer Rotary Group Members with One Dial-In Number

The following example, a dialer rotary group with two members each with the same number, accepts incoming dial attempts. The dialer interface has a base phone number because each of its member interfaces is in a hunt group and the same number can be used to access each individual interface.

interface bri 0

no ip address

encapsulation ppp

dialer rotary-group 1

no fair-queue

no cdp enable

!

interface bri 1

no ip address

encapsulation ppp

dialer rotary-group 1

no fair-queue

no cdp enable

!

interface dialer 1

ip unnumbered Ethernet0

encapsulation ppp

dialer in-band

dialer idle-timeout 300

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap

ppp multilink bap

ppp bap call accept

ppp bap callback request

ppp bap timeout pending 20

ppp bap timeout response 2

ppp bap max dial-attempts 2

ppp bap monitor load

ppp bap number default 6666666

PRI Interface with No Defined PPP BACP Number

In the following example, a PRI interface has no BACP number defined and accepts incoming dial attempts (passive mode). The PRI interface has no base phone number defined, so each attempt to add a link would result in a delta of zero being provided to the calling peer. To establish the bundle, the peer should then dial the same number as it originally used.

interface serial 0:23

ip unnumbered Ethernet0

encapsulation ppp

dialer in-band

dialer idle-timeout 300

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap

ppp multilink bap

ppp bap call accept

ppp bap callback request

ppp bap timeout pending 20

ppp bap timeout response 2

ppp bap max dial-attempts 2

ppp bap monitor load

BRI Interface with No Defined BACP Number

In the following example, the BRI interface has no base phone number defined. The number that it uses to establish the bundle is that from the dialer map, and all phone delta operations are applied to that number.

interface bri 0

ip unnumbered Ethernet0

encapsulation ppp

dialer in-band

dialer idle-timeout 300

dialer map ip 10.1.1.1 name bap_peer speed 56 19998884444

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap

ppp multilink bap

ppp bap call request

ppp bap timeout pending 20

ppp bap timeout response 2

ppp bap max dial-attempts 2

ppp bap monitor load

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001–2009 Cisco Systems, Inc. All rights reserved.

Configuring an IP Local Pools Holdback Timer

The IP Local Pools Holdback Timer feature allows you to configure a delay in the recycle of free IP addresses from the local pool. You can configure a unique IP address list for each pool.

command in global configuration mode to configure the list of IP addresses to delay before recycling and set the recycle delay time.

Feature History for IP Local Pools Holdback Timer

Release

Modification

12.4(15)T

This feature was introduced.

Contents

- Prerequisites for the IP Local Pools Holdback Timer

- Information About the IP Local Pools Holdback Timer

- How to Configure the IP Local Pools Holdback Timer

- Additional References

Prerequisites for the IP Local Pools Holdback Timer

- Establish a working Point-to-Point Protocol over Ethernet (PPPoE) 802.IQ network

- Establish IP local pools

Information About the IP Local Pools Holdback Timer

The IP Local Pools Holdback Timer feature allows you to configure a recycle delay for each free IP address before it returns to a local pool for reassignment to a different user. You can configure a holdback timers with unique values, one for each pool, and track each pool separately.

The IP Local Pools Holdback Timer feature adds a time-stamp field to the pool element data structure that delays the reuse of the released IP address. The time-stamp field sets whenever the state of the pool element returns to POOL_ELEMENT_FREE, and the element returns to the Free Queue.

When there is a request for a specific IP address that is available for assignment, then the current time is compared against the time stamp configured for that IP address. If the time stamp equals or exceeds the configured recycle delay, the IP address is freed for assignment.

If the compared time difference is lower than the configured recycle delay, and if no other free IP addresses are available, the address allocation request is denied.

If there are free IP addresses when a request is made to get the first free IP address from the free queue, the difference between the current time stamp and the time stamp stored for the first IP address is calculated. If the difference equals or exceeds the configured recycle delay, the IP address is allocated to the peer.

If the configured recycle delay in not equal or exceeded, then the request is denied. Because the free queue is a first-in, first-out (FIFO) queue, all the other IP addresses will have a greater recycle delay than the first IP address. When an address assignment request is denied because the IP address recycle delay time has not expired, a count increments for the pool.

An IP address from the pool is marked as an orphan, when the IP address is still in use but the underlying IP pool has been removed or changed. In these cases, there is no pool for the IP address to return to when the session terminates. The IP address frees immediately and no recycle delay is applied.

How to Configure the IP Local Pools Holdback Timer

To configure an IP local pool holdback timer, follow these steps:

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# ip local pool example 10.1.1.1 10.2.1.1 recycle delay 30

Sets the IP local pool recycle delay for the poolname.

Step 4

Router(config)# exit

Exits the current mode.

Configurating an IP Local Pools Holdback Timer: Example

The following example shows how to configure an IP local pools holdback timer of 30 seconds for the local pool example_pool for the IP address range 10.1.1.1 through 10.2.1.1:

gateway> enable

gateway# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

gateway(config)# ip local pools example_pool 10.1.1.1 10.2.1.1 recycle delay 30

Additional References

The following sections provide references related to the IP Local Pools Holdback Timer feature.

MIBs

MIB

MIBs Link

None

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

Technical Assistance

Description

Link

The Cisco Technical Support website contains thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

© 2001–2009 Cisco Systems, Inc. All rights reserved.

Configuring per-User Configuration

This chapter describes per-user configuration, a large-scale dial solution. It includes the following main sections:

- Per-User Configuration Overview

- How to Configure a AAA Server for Per-User Configuration

- Monitoring and Debugging Per-User Configuration Settings

- Configuration Examples for Per-User Configuration

This set of features is supported on all platforms that support Multilink PPP (MLP).

A virtual access interface created dynamically for any user dial-in session is deleted when the session ends. The resources used during the session are returned for other dial-in uses.

When a specific user dials in to a router, the use of a per-user configuration from an authentication, authorization, and accounting (AAA) server requires that AAA is configured on the router and that a configuration for that user exists on the AAA server.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

, Release 12.2. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

Per-User Configuration Overview

Per-user configuration provides a flexible, scalable, easily maintained solution for customers with a large number of dial-in users. This solution can tie together the following dial-in features:

- Virtual template interfaces, generic interface configuration and router-specific configuration information stored in the form of a virtual template interface that can be applied ( cloned ) to a virtual access interface each time any user dials in. This configuration is described in the chapter “Configuring Virtual Template Interfaces” in this publication.

- AAA per-user security and interface configuration information stored on a separate AAA server and sent by the AAA server to the access server or router in response to authorization requests during the PPP authentication phase. The per-user configuration information can add to or override the generic configuration on a virtual interface.

- Virtual profiles, which can use either or both of the two sources of information listed in the previous bullets for virtual interface configuration. When a user dials in, virtual profiles can apply the generic interface configuration and then apply the per-user configuration to create a unique virtual access interface for that user. This configuration is described in the chapter “Configuring Virtual Profiles” in this publication.

The per-user configuration feature provides these benefits:

- Maintenance ease for service providers with a large number of access servers and a very large number of dial-in users. Service providers need not update all their routers and access servers when user-specific information changes; instead, they can update one AAA server.

- Scalability. By separating generic virtual interface configuration on the router from the configuration for each individual, Internet service providers and other enterprises with large numbers of dial-in users can provide a uniquely configured interface for each individual user. In addition, by separating the generic virtual interface configuration from the physical interfaces on the router, the number and types of physical interfaces on the router or access server are not intrinsic barriers to growth.

General Operational Processes

In general, the per-user configuration process on the Cisco router or network access server proceeds as follows:

1. The user dials in.

2. The authentication and authorization phases occur.

a. If AAA is configured, the router sends an authorization request to the AAA server.

b. If the AAA server has information (attribute-value or AV pairs, or other configuration parameters) that defines a configuration for the specific user, the server includes it in the information in the approval response packet.

Figure 1 illustrates the request and response part of the process that happens when a user dials in, given that AAA is configured and that the AAA server has per-user configuration information for the dial-in user.

c. The router looks for AV pairs in the AAA approval response.

d. The router caches the configuration parameters.

Note TACACS servers treat authentication and authorization as two phases; RADIUS servers combine authentication and authorization into a single step. For more detailed information, refer to your server documentation.

Figure 1 Per-User Configuration Authentication and Authorization

3. A virtual access interface is created for this user.

a. The router finds the virtual template that is set up for virtual profiles, if any, and applies the commands to the virtual access interface.

b. The router looks for the AV pairs to apply to this virtual access interface to configure it for the dial-in user.

c. The AV pairs are sent to the Cisco IOS command-line parser, which interprets them as configuration commands and applies them to configure this virtual access interface.

The result of this process is a virtual access interface configured uniquely for the dial-in user.

When the user ends the call, the virtual access interface is deleted and its resources are returned for other dial-in uses.

Note The use of virtual profiles can modify the process that occurs between the user dial-in and the use of AAA configuration information. For more information, see the chapter “Configuring Virtual Profiles” in this publication.

Operational Processes with IP Address Pooling

During IP Control Protocol (IPCP) address negotiation, if an IP pool name is specified for a user, the network access server checks whether the named pool is defined locally. If it is, no special action is required and the pool is consulted for an IP address.

If the required pool is not present (either in the local configuration or as a result of a previous download operation), an authorization call to obtain it is made using the special username:

pools-nas-name

is the configured name of the network access server. In response, the AAA server downloads the configuration of the required pool.

This pool username can be changed using Cisco IOS configuration, for example:

aaa configuration config-name nas1-pools-definition.cisco.us

to “nas1-pools-definition.cisco.com.”

On a TACACS+ server, the entries for an IP address pool and a user of the pool might be as follows:

user = nas1-pools {

service = ppp protocol = ip {

pool-def#1 = "aaa 10.0.0.1 10.0.0.3"

pool-def#2 = "bbb 10.1.0.1 10.1.0.10"

pool-def#3 = "ccc 10.2.0.1 10.2.0.20"

pool-timeout=60

}

}

user = georgia {

login = cleartext lab

service = ppp protocol = ip {

addr-pool=bbb

}

}

On a RADIUS server, the entries for the same IP address pool and user would be as follows:

nas1-pools Password = “cisco” User-Service-Type=Outbound-User

cisco-avpair = "ip:pool-def#1=aaa 10.0.0.1 10.0.0.3",

cisco-avpair = "ip:pool-def#2=bbb 10.1.0.1 10.1.0.10",

cisco-avpair = "ip:pool-def#3=ccc 10.2.0.1 10.2.0.20",

cisco-avpair = "ip:pool-timeout=60”

georgia Password = “lab”

User-Service-Type = Framed-User,

Framed-Protocol = PPP,

cisco-avpair = “ip:addr-pool=bbb”

Note This entry specifies a User-Service-Type of Outbound-User. This attribute is supplied by the network access server to prevent ordinary logins from using the well-known username and password combination of nas1-pools/cisco.

command.

Deleting Downloaded Pools

To delete downloaded pools, you can do either of the following:

- Manually delete the definition from the network access server. For example, if “bbb” is the name of a downloaded pool, you can enter the Cisco IOS no ip local pool bbb command.

Deleting a pool definition does not interrupt service for current users. If a pool is deleted and then redefined to include a pool address that is currently allocated, the new pool understands and tracks the address as expected.

- Set an AV pair pool-timeout value; this is a more desirable solution.

The pool-timeout AV pair starts a timer when the pool is downloaded. Once the timer expires, the pools are deleted. The next reference to the pools again causes an authorization call to be made, and the pool definition is downloaded again. This method allows definitions to be made and changed on the AAA server and propagated to network access servers.

Supported Attributes for AV Pairs

.

Table 1 Partial List of Cisco-Specific Supported AV Pair Attributes

Attribute

Meaning

inacl#

An input access list definition. For IP, standard or extended access list syntax can be used, although you cannot mix them within a single list. For Internet Protocol Exchange (IPX), only extended syntax is recognized. The value of this attribute is the text that comprises the body of a named access list definition.

outacl#1

An output access list definition. For IP, standard or extended access list syntax can be used. For IPX, only extended syntax is recognized. The value of this attribute is the text that comprises the body of a named access list definition.

rte-fltr-in#

An input route filter. For IP, standard or extended access list syntax can be used, although you cannot mix them within a single list. For IPX, only extended syntax is recognized. The first line of this filter must specify a routing process. Subsequent lines comprise the body of a named access list.

rte-fltr-out#

An output route filter. For IP, standard or extended access list syntax can be used, although you cannot mix them within a single list. For IPX, only extended syntax is recognized. The first line of this filter must specify a routing process. Subsequent lines comprise the body of a named access list.

route#2

Static routes, for IP and IPX.

].

sap#

configuration command.

sap-fltr-in#

configuration command. (The Novell socket number for SAP filtering is 452.)

sap-fltr-out#

command syntax is recognized. The value is text from the body of an extended IPX access-list configuration command.

pool-def#

configuration command.

pool-timeout

An IP pool definition. The body is an integer representing a timeout, in minutes.

1.The “outacl” attribute still exists and retains its old meaning.

1.The “outacl” attribute still exists and retains its old meaning.

2.The “route” attribute, without a trailing #, is still recognized for backward compatibility with the TACACS+ protocol specification, but if multiple static routes are required in TACACS+, full “route#” names will need to be employed.

2.The “route” attribute, without a trailing #, is still recognized for backward compatibility with the TACACS+ protocol specification, but if multiple static routes are required in TACACS+, full “route#” names will need to be employed.

provides examples for each attribute on an AAA TACACS+ server.

Table 2 TACACS+ Server AV Pair Examples for Each Attribute

Attribute

TACACS+ Server Examples

inacl#

IP:

inacl#3="permit ip any any precedence immediate"

inacl#4="deny igrp 10.0.1.2 255.255.0.0 any"

IPX:

inacl#1="deny 3C01.0000.0000.0001"

inacl#2="deny 4C01.0000.0000.0002"

outacl#

outacl#2="permit ip any any precedence immediate"

outacl#3="deny igrp 10.0.9.10 255.255.0.0 any"

rte-fltr-in#

IP:

rte-fltr-in#1="router igrp 60"

rte-fltr-in#3="permit 10.0.3.4 255.255.0.0"

rte-fltr-in#4="deny any"

IPX:

rte-fltr-in#1="deny 3C01.0000.0000.0001"

rte-fltr-in#2="deny 4C01.0000.0000.0002"

rte-fltr-out#

rte-fltr-out#1="router igrp 60"

rte-fltr-out#3="permit 10.0.5.6 255.255.0.0"

rte-fltr-out#4="permit any"

route#

IP:

route#1="10.0.0.0 255.0.0.0 1.2.3.4"

route#2="10.1.0.0 255.0.0.0"

IPX:

route#1="4C000000 ff000000 10.12.3.4"

route#2="5C000000 ff000000 10.12.3.5"

sap#

sap#1="4 CE1-LAB 1234.0000.0000.0001 451 4"

sap#2="5 CE3-LAB 2345.0000.0000.0001 452 5"

sap-fltr-in#

sap-fltr-in#1="deny 6C01.0000.0000.0001"

sap-fltr-in#2="permit -1"

sap-fltr-out#

sap-fltr-out#1="deny 6C01.0000.0000.0001"

sap-fltr-out#2="permit -1"

pool-def#

pool-def#1 = "aaa 10.0.0.1 1.0.0.3"

pool-def#2 = "bbb 10.1.0.1 2.0.0.10"

pool-def#3 = "ccc 10.2.0.1 3.0.0.20"

pool-timeout

pool-timeout=60

provides examples for each attribute on an AAA RADIUS server.

Table 3 RADIUS Server AV Pair Examples for Each Attribute

Attribute

RADIUS Server Examples

lcp:interface-config3

cisco-avpair = "lcp:interface-config=ip address 10.0.0.0 255.255.255.0",

inacl#

cisco-avpair = "ip:inacl#3=permit ip any any precedence immediate",

cisco-avpair = "ip:inacl#4=deny igrp 10.0.1.2 255.255.0.0 any",

outacl#

cisco-avpair = "ip:outacl#2=permit ip any any precedence immediate",

cisco-avpair = "ip:outacl#3=deny igrp 10.0.9.10 255.255.0.0 any",

rte-fltr-in#

IP:

cisco-avpair = "ip:rte-fltr-in#1=router igrp 60",

cisco-avpair = "ip:rte-fltr-in#3=permit 10.0.3.4 255.255.0.0",

cisco-avpair = "ip:rte-fltr-in#4=deny any",

IPX:

cisco-avpair = "ipx:rte-fltr-in=deny 3C01.0000.0000.0001",

rte-fltr-out#

cisco-avpair = "ip:rte-fltr-out#1=router igrp 60",

cisco-avpair = "ip:rte-fltr-out#3=permit 10.0.5.6 255.255.0.0",

cisco-avpair = "ip:rte-fltr-out#4=permit any",

route#

IP:

cisco-avpair = "ip:route=3.10.0.0 255.0.0.0 1.2.3.4",

cisco-avpair = "ip:route=4.10.0.0 255.0.0.0",

IPX:

cisco-avpair = "ipx:route=4C000000 ff000000 10.12.3.4",

cisco-avpair = "ipx:route=5C000000 ff000000 10.12.3.5"

sap#

cisco-avpair = "ipx:sap=4 CE1-LAB 1234.0000.0000.0001 451 4",

cisco-avpair = "ipx:sap=5 CE3-LAB 2345.0000.0000.0001 452 5",

sap-fltr-in#

cisco-avpair = "ipx:sap-fltr-in=deny 6C01.0000.0000.0001",

cisco-avpair = "ipx:sap-fltr-in=permit -1"

sap-fltr-out#

cisco-avpair = "ipx:sap-fltr-out=deny 6C01.0000.0000.0001",

cisco-avpair = "ipx:sap-fltr-out=permit -1"

pool-def#

cisco-avpair = "ip:pool-def#1=aaa 10.0.0.1 1.0.0.3",

cisco-avpair = "ip:pool-def#2=bbb 10.1.0.1 2.0.0.10",

cisco-avpair = "ip:pool-def#3=ccc 10.2.0.1 3.0.0.20",

pool-timeout

cisco-avpair = "ip:pool-timeout=60"

3.This attribute is specific to RADIUS servers. It can be used to add Cisco IOS interface configuration commands to specific user configuration information.

3.This attribute is specific to RADIUS servers. It can be used to add Cisco IOS interface configuration commands to specific user configuration information.

How to Configure a AAA Server for Per-User Configuration

The configuration requirements and the structure of per-user configuration information is set by the specifications of each type of AAA server. Refer to your server documentation for more detailed information. The following sections about TACACS and RADIUS servers are specific to per-user configuration:

- Configuring a Freeware TACACS Server for Per-User Configuration (As required)

- Configuring a CiscoSecure TACACS Server for Per-User Configuration (As required)

- Configuring a RADIUS Server for Per-User Configuration (As required)

See the section “Monitoring and Debugging Per-User Configuration Settings” later in this chapter for tips on troubleshooting per-user configuration settings. See the section “Configuration Examples for Per-User Configuration” at the end of this chapter for examples of configuring RADIUS and TACACS servers.

Configuring a Freeware TACACS Server for Per-User Configuration

On a TACACS server, the entry in the user file takes a standard form. In the freeware version of TACACS+, the following lines appear in order:

- “User =” followed by the username, a space, and an open brace

- Authentication parameters

- Authorization parameters

- One or more AV pairs

- End brace on a line by itself

The general form of a freeware TACACS user entry is shown in the following example:

user = username {

authentication parameters go here

authorization parameters go here

}

The freeware TACACS user entry form is also shown by the following examples for specific users:

user= Router1

Password= cleartext welcome

Service= PPP protocol= ip {

ip:route=10.0.0.0 255.0.0.0

ip:route=10.1.0.0 255.0.0.0

ip:route=10.2.0.0 255.0.0.0

ip:inacl#5=deny 10.5.0.1

}

user= Router2

Password= cleartext lab

Service= PPP protocol= ip {

ip:addr-pool=bbb

}

For more requirements and detailed information, refer to your AAA server documentation.

Configuring a CiscoSecure TACACS Server for Per-User Configuration

The format of an entry in the user file in the AAA database is generally name = value. Some values allow additional subparameters to be specified and, in these cases, the subparameters are enclosed in braces ({}). The following simple example depicts an AAA database showing the default user, one group, two users that belong to the group, and one user that does not:

# Sample AA Database 1

unknown_user = {

password = system #Use the system's password file (/etc/passwd)

}

group = staff {

# Password for staff who do not have their own.

password = des "sefjkAlM7zybE"

service = shell {

# Allow any commands with any attributes.

default cmd = permit

default attribute = permit

}

}

user = joe { # joe uses the group password.

member = "staff"

}

user = pete { # pete has his own password.

member = "staff"

password = des "alkd9Ujiqp2y"

}

user = anita {

# Use the "default" user password mechanism defined above.

service = shell {

cmd = telnet { # Allow Telnet to any destination

}

}

}

.

Configuring a RADIUS Server for Per-User Configuration

On a RADIUS server, the format of an entry in the users file includes the following lines in order:

- Username and password

- User service type

- Framed protocol

- One or more AV pairs

Note All these AV pairs are vendor specific. To use them, RADIUS servers must support the use of vendor-specific AV pairs. Patches for some servers are available from the Cisco Consulting Engineering (CE) customer-support organization.

followed by a space, an equal sign, and another space. The rest of the line is within double quotation marks and, for all lines but the last, ends with a comma. Inside the double quotation marks is a phrase indicating the supported attribute, another equal sign, and a Cisco IOS command. The following examples show two different partial user configurations on a RADIUS server.

Router1

Password = "welcome"

User-Service-Type = Framed-User,

Framed-Protocol = PPP,

cisco-avpair = “ip:route=10.0.0.0 255.0.0.0”,

cisco-avpair = “ip:route=10.1.0.0 255.0.0.0”,

cisco-avpair = “ip:route=10.2.0.0 255.0.0.0”,

cisco-avpair = “ip:inacl#5=deny 10.5.0.1”

Router2

Password = "lab"

User-Service-Type = Framed-User,

Framed-Protocol = PPP,

cisco-avpair = "ip:addr-pool=bbb"

Monitoring and Debugging Per-User Configuration Settings

Per-user configuration information exists on AAA servers only and is configured there, as described in the “How to Configure a AAA Server for Per-User Configuration” section.

For more information about configuring an application that can tie AAA per-user configuration information to generic interface and router configuration, see the chapter “Configuring Virtual Profiles” in this publication. Virtual profiles are required for combining per-user configuration information and generic interface and router configuration information to create virtual access interfaces for individual ISDN B channels.

indicates some of the commands to use for each attribute.

Table 4 Monitoring and Debugging Per-User Configuration Commands

Attribute

show Commands

debug Commands

outacl#

rte-fltr-out#

route#

sap#

sap-fltr-out#

pool-timeout

]

—

Configuration Examples for Per-User Configuration

The following sections provide two comprehensive examples:

- TACACS+ Freeware Examples

- RADIUS Examples

These examples show router or access server configuration and AV pair configuration on an AAA server.

TACACS+ Freeware Examples

This section provides the TACACS+ freeware versions of the following examples:

- IP Access Lists and Static Routes Using Virtual Profiles over ISDN BRI

- IPX Per-User SAP Filters Using IPXWAN and Virtual Profiles by a Synchronous Interface

IP Access Lists and Static Routes Using Virtual Profiles over ISDN BRI

The following example provides configurations for the TACACS+ freeware daemon, the network access server, and the peer router named Router1. On the TACACS+ AAA server, peer router Router1 has a configuration that includes static routes and IP access lists.

TACACS+ Freeware Daemon Configuration File

key = tac123

user = Router1 {

global = cleartext welcome

service = ppp protocol = ip {

route#1=”10.0.0.0 255.0.0.0"

route#2=”10.1.0.0 255.0.0.0"

route#3=”10.2.0.0 255.0.0.0"

inacl#1=”deny 10.5.0.1"

}

}

Current Network Access Server Configuration

version 11.3

service timestamps debug datetime localtime

service udp-small-servers

service tcp-small-servers

!

hostname Router2

!

aaa new-model

aaa authentication ppp default tacacs+

aaa authorization network tacacs+

enable secret 5 $1$koOn$/1QAylov6JFAElxRCrL.o/

enable password lab

!

username Router1 password 7 15050E0007252621

ip host Router2 172.21.114.132

ip domain-name cisco.com

ip name-server 172.19.2.132

ip name-server 192.168.30.32

isdn switch-type basic-5ess

interface Ethernet 0

ip address 172.21.114.132 255.255.255.224

no ip mroute-cache

media-type 10BaseT

!

interface Virtual-Template1

ip unnumbered Ethernet0

no cdp enable

!

!

interface BRI0

ip unnumbered Ethernet0

no ip mroute-cache

encapsulation ppp

no ip route-cache

dialer idle-timeout 300

dialer map ip 10.5.0.1 name Router1 broadcast 61482

dialer-group 1

no fair-queue

ppp authentication chap

!

!

ip default-gateway 172.21.114.129

no ip classless

ip route 0.0.0.0 0.0.0.0 172.21.114.129

!

virtual-profile virtual-template 1

dialer-list 1 protocol ip permit

tacacs-server host 172.21.114.130

tacacs-server key tac123

Current Peer Configuration for Router1

version 11.3

no service pad

!

hostname Router1

!

enable secret 5 $1$m1WK$RsjborN1Z.XZuFqsrtSnp/

enable password lab

!

username Router2 password 7 051C03032243430C

ip host Router1 172.21.114.134

ip domain-name cisco.com

ip name-server 172.19.2.132

ip name-server 192.168.30.32

isdn switch-type basic-5ess

!

interface Ethernet0

ip address 172.21.114.134 255.255.255.224

no ip route-cache

shutdown

!

interface BRI0

ip address 10.5.0.1 255.0.0.0

encapsulation ppp

dialer map ip 172.21.114.132 name Router2 broadcast 61483

dialer-group 1

no fair-queue

!

ip default-gateway 172.21.114.129

no ip classless

ip route 172.21.0.0 255.255.0.0 BRI0

dialer-list 1 protocol ip permit

!

line con 0

exec-timeout 0 0

line vty 0 4

password lab

login

end

IPX Per-User SAP Filters Using IPXWAN and Virtual Profiles by a Synchronous Interface

The following example provides configurations for the TACACS+ daemon and the peer router named Router1. On the TACACS+ AAA server, user ny has a configuration that includes inbound and outbound SAP filters.

TACACS+ Freeware Daemon Configuration File for User

key = tac123

user = Router1 {

global = cleartext welcome

service = ppp protocol = ipx {

sap=”101 CYBER-01 40.0000.0000.0001 400 10"

sap=”202 CYBER-02 40.0000.0000.0001 401 10"

sap=”303 CYBER-03 40.0000.0000.0001 402 10"

sap-fltr-out#1=”deny 40 101"

sap-fltr-out#2=”deny 40 202"

sap-fltr-out#3=”permit -1"

sap-fltr-in#1=”permit 30 444"

sap-fltr-in#2=”deny -1"

Current Remote Peer (Router1) Configuration

version 11.3

!

hostname Router1

!

enable password lab

!

username Router2 password 7 140017070F0B272E

ip host Router1 172.21.114.131

ip name-server 172.19.2.132

ip name-server 192.168.30.32

ipx routing 0000.0c47.090d

ipx internal-network 30

!

interface Ethernet0

ip address 172.21.114.131 255.255.255.224

!

interface Serial1

no ip address

encapsulation ppp

ipx ipxwan 0 unnumbered peer-Router1

clockrate 4000000

!

ipx sap 444 ZEON-4 30.0000.0000.0001 444 10

ipx sap 555 ZEON-5 30.0000.0000.0001 555 10

ipx sap 666 ZEON-6 30.0000.0000.0001 666 10

!

Current Network Access Server (Router2) Configuration

version 11.3

service timestamps debug uptime

!

hostname Router2

!

aaa new-model

aaa authentication ppp default tacacs+

aaa authorization network tacacs+

enable password lab

!

username Router1 password 7 044C0E0A0C2E414B

ip host LA 172.21.114.133

ip name-server 192.168.30.32

ip name-server 172.19.2.132

ipx routing 0000.0c47.12d3

ipx internal-network 40

!

interface Ethernet0

ip address 172.21.114.133 255.255.255.224

!

interface Virtual-Template1

no ip address

ipx ipxwan 0 unnumbered nas-Router2

no cdp enable

!

interface Serial1

ip unnumbered Ethernet0

encapsulation ppp

ipx ipxwan 0 unnumbered nas-Router2

ppp authentication chap

!

ipx sap 333 DEEP9 40.0000.0000.0001 999 10

!

virtual-profile virtual-template 1

tacacs-server host 172.21.114.130

tacacs-server key tac123

RADIUS Examples

This section provides the RADIUS versions of the following examples:

- IP Access Lists and Static Routes Using Virtual Profiles over ISDN BRI

- IPX Per-User SAP Filters Using IPXWAN and Virtual Profiles by a Synchronous Interface

IP Access Lists and Static Routes Using Virtual Profiles over ISDN BRI

The following example shows a remote peer (Router1) configured to dial in to a BRI on a Cisco network access server (Router2), which requests user configuration information from an AAA server (radiusd):

RADIUS User File (Router1)

Password = "welcome"

User-Service-Type = Framed-User,

Framed-Protocol = PPP,

cisco-avpair = "ip:route=10.1.0.0 255.0.0.0",

cisco-avpair = "ip:route=10.2.0.0 255.0.0.0",

cisco-avpair = "ip:route=10.3.0.0 255.0.0.0",

cisco-avpair = "ip:inacl#5=deny 10.0.0.1"

Current Network Access Server Configuration

version 11.3

service timestamps debug datetime localtime

service udp-small-servers

service tcp-small-servers

!

hostname Router2

!

aaa new-model

aaa authentication ppp default radius

aaa authorization network radius

enable secret 5 $1$koOn$/1QAylov6JFAElxRCrL.o/

enable password lab

!

username Router1 password 7 15050E0007252621

ip host Router2 172.21.114.132

ip domain-name cisco.com

ip name-server 172.19.2.132

ip name-server 192.168.30.32

isdn switch-type basic-5ess

interface Ethernet0

ip address 172.21.114.132 255.255.255.224

no ip mroute-cache

media-type 10BaseT

!

interface Virtual-Template1

ip unnumbered Ethernet0

no cdp enable

!

interface BRI0

ip unnumbered Ethernet0

no ip mroute-cache

encapsulation ppp

no ip route-cache

dialer idle-timeout 300

dialer map ip 10.5.0.1 name Router1 broadcast 61482

dialer-group 1

no fair-queue

ppp authentication chap

!

ip default-gateway 172.21.114.129

no ip classless

ip route 0.0.0.0 0.0.0.0 172.21.114.129

!

virtual-profile vtemplate 1

dialer-list 1 protocol ip permit

radius-server host 172.21.114.130

radius-server key rad123

Current Peer Configuration for Router1

version 11.3

no service pad

!

hostname Router1

!

enable secret 5 $1$m1WK$RsjborN1Z.XZuFqsrtSnp/

enable password lab

!

username Router2 password 7 051C03032243430C

ip host Router1 172.21.114.134

ip domain-name cisco.com

ip name-server 172.19.2.132

ip name-server 192.168.30.32

isdn switch-type basic-5ess

!

interface Ethernet0

ip address 172.21.114.134 255.255.255.224

no ip route-cache

shutdown

!

interface BRI0

ip address 10.5.0.1 255.0.0.0

encapsulation ppp

dialer map ip 172.21.114.132 name Router2 broadcast 61483

dialer-group 1

no fair-queue

!

ip default-gateway 172.21.114.129

no ip classless

ip route 172.21.0.0 255.255.0.0 BRI0

dialer-list 1 protocol ip permit

!

line con 0

exec-timeout 0 0

line vty 0 4

password lab

login

!

end

Output of ping Command from Router1

Router1# ping 172.21.114.132

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.21.114.132, timeout is 2 seconds:

U.U.U

Success rate is 0 percent (0/5)

(fails due to access list deny)

RADIUS Debug Output

radrecv: Request from host ac157284 code=1, id=46, length=67

Client-Id = 172.21.114.132

Client-Port-Id = 1112670208

User-Name = “Router1”

CHAP-Password = “\037\317\213\326*\236)#+\266\243\255x\331\370v\334”

User-Service-Type = Framed-User

Framed-Protocol = PPP

Sending Ack of id 46 to ac157284 (172.21.114.132)

User-Service-Type = Framed-User

Framed-Protocol = PPP

[Vendor 9] cisco-avpair = “ip:route=10.0.0.0 255.0.0.0”

[Vendor 9] cisco-avpair = “ip:route=10.1.0.0 255.0.0.0”

[Vendor 9] cisco-avpair = “ip:route=10.2.0.0 255.0.0.0”

[Vendor 9] cisco-avpair = “ip:inacl#5=deny 10.0.0.1”

Network Access Server (Router2) show and debug Command Output

Router2# show debug

General OS:

AAA Authorization debugging is on

PPP:

PPP authentication debugging is on

Multilink activity debugging is on

ISDN:

ISDN events debugging is on

Dial on demand:

Dial on demand events debugging is on

VTEMPLATE:

Virtual Template debugging is on

pr 4 08:30:09: ISDN BR0: received HOST_INCOMING_CALL

Bearer Capability i = 0x080010

*Apr 4 08:30:09: -------------------

Channel ID i = 0x0101

*Apr 4 08:30:09: IE out of order or end of ‘private’ IEs --

Bearer Capability i = 0x8890

*Apr 4 08:30:09: Channel ID i = 0x89

*Apr 4 08:30:09: Called Party Number i = 0xC1, ‘61483’

*Apr 4 08:30:09: ISDN BR0: Event: Received a call from <unknown> on B1 at 64 Kb/s

*Apr 4 08:30:09: ISDN BR0: Event: Accepting the call

%LINK-3-UPDOWN: Interface BRI0:1, changed state to up

*Apr 4 08:30:09: ISDN BR0: received HOST_CONNECT

Channel ID i = 0x0101

*Apr 4 08:30:09: -------------------

Channel ID i = 0x89

*Apr 4 08:30:09: ISDN BR0: Event: Connected to <unknown> on B1 at 64 Kb/s

*Apr 4 08:30:09: PPP BRI0:1: Send CHAP challenge id=30 to remote

*Apr 4 08:30:10: PPP BRI0:1: CHAP response received from Router1

*Apr 4 08:30:10: PPP BRI0:1: CHAP response id=30 received from Router1

*Apr 4 08:30:10: AAA/AUTHOR/LCP: authorize LCP

*Apr 4 08:30:10: AAA/AUTHOR/LCP: BRI0:1: (0): user=’Router1’

*Apr 4 08:30:10: AAA/AUTHOR/LCP: BRI0:1: (0): send AV service=ppp

*Apr 4 08:30:10: AAA/AUTHOR/LCP: BRI0:1: (0): send AV protocol=lcp

*Apr 4 08:30:10: AAA/AUTHOR/LCP: BRI0:1: (2084553184): Method=RADIUS

*Apr 4 08:30:10: AAA/AUTHOR (2084553184): Post authorization status = PASS_ADD

*Apr 4 08:30:10: PPP BRI0:1: Send CHAP success id=30 to remote

*Apr 4 08:30:10: PPP BRI0:1: remote passed CHAP authentication.

*Apr 4 08:30:10: VTEMPLATE Reuse vaccess1, New Recycle queue size:0

*Apr 4 08:30:10: VTEMPLATE set default vaccess1 with no ip address

*Apr 4 08:30:10: Virtual-Access1 VTEMPLATE hardware address 0000.0c46.154a

*Apr 4 08:30:10: VTEMPLATE vaccess1 has a new cloneblk vtemplate, now it has vtemplate

*Apr 4 08:30:10: VTEMPLATE undo default settings vaccess1

*Apr 4 08:30:10: VTEMPLATE ************* CLONE VACCESS1 ******************Apr 4 08:30:10: VTEMPLATE Clone from vtemplate1 to vaccess1

interface Virtual-Access1

no ip address

encap ppp

ip unnumbered ethernet 0

end

%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up

*Apr 4 08:30:10: AAA/AUTHOR/LCP: authorize LCP

*Apr 4 08:30:10: AAA/AUTHOR/LCP: Virtual-Access1: (0): user=’Router1’

*Apr 4 08:30:10: AAA/AUTHOR/LCP: Virtual-Access1: (0): send AV service=ppp

*Apr 4 08:30:10: AAA/AUTHOR/LCP: Virtual-Access1: (0): send AV protocol=lcp

*Apr 4 08:30:10: AAA/AUTHOR/LCP: Virtual-Access1: (1338953760): Method=RADIUS

*Apr 4 08:30:10: AAA/AUTHOR (1338953760): Post authorization status = PASS_ADD

*Apr 4 08:30:10: AAA/AUTHOR/FSM: Virtual-Access1: (0): can we start IPCP?

*Apr 4 08:30:10: AAA/AUTHOR/FSM: Virtual-Access1: (0): user=’Router1’

*Apr 4 08:30:10: AAA/AUTHOR/FSM: Virtual-Access1: (0): send AV service=ppp

*Apr 4 08:30:10: AAA/AUTHOR/FSM: Virtual-Access1: (0): send AV protocol=ip

*Apr 4 08:30:10: AAA/AUTHOR/FSM: Virtual-Access1: (1716082074): Method=RADIUS

*Apr 4 08:30:10: AAA/AUTHOR (1716082074): Post authorization status = PASS_ADD

*Apr 4 08:30:10: AAA/AUTHOR/FSM: Virtual-Access1: we can start IPCP (0x8021)

*Apr 4 08:30:10: MLP Bad link Virtual-Access1

*Apr 4 08:30:10: AAA/AUTHOR/FSM: Virtual-Access1: (0): can we start UNKNOWN?

*Apr 4 08:30:10: AAA/AUTHOR/FSM: Virtual-Access1: (0): user=’Router1’

*Apr 4 08:30:10: AAA/AUTHOR/FSM: Virtual-Access1: (0): send AV service=ppp

*Apr 4 08:30:10: AAA/AUTHOR/FSM: Virtual-Access1: (0): send AV protocol=unknown

*Apr 4 08:30:10: AAA/AUTHOR/FSM: Virtual-Access1: (2526612868): Method=RADIUS

*Apr 4 08:30:10: AAA/AUTHOR (2526612868): Post authorization status = PASS_ADD

*Apr 4 08:30:10: AAA/AUTHOR/FSM: Virtual-Access1: we can start UNKNOWN (0x8207)

*Apr 4 08:30:10: MLP Bad link Virtual-Access1

*Apr 4 08:30:10: BRI0:1: Vaccess started from dialer_remote_name

*Apr 4 08:30:10: AAA/AUTHOR/FSM: BRI0:1: (0): can we start IPCP?

*Apr 4 08:30:10: AAA/AUTHOR/FSM: BRI0:1: (0): user=’Router1’

*Apr 4 08:30:10: AAA/AUTHOR/FSM: BRI0:1: (0): send AV service=ppp

*Apr 4 08:30:10: AAA/AUTHOR/FSM: BRI0:1: (0): send AV protocol=ip

*Apr 4 08:30:10: AAA/AUTHOR/FSM: BRI0:1: (3920403585): Method=RADIUS

*Apr 4 08:30:10: AAA/AUTHOR (3920403585): Post authorization status = PASS_ADD

*Apr 4 08:30:10: AAA/AUTHOR/FSM: BRI0:1: we can start IPCP (0x8021)

*Apr 4 08:30:10: AAA/AUTHOR/FSM: BRI0:1: (0): can we start UNKNOWN?

*Apr 4 08:30:10: AAA/AUTHOR/FSM: BRI0:1: (0): user=’Router1’

*Apr 4 08:30:10: AAA/AUTHOR/FSM: BRI0:1: (0): send AV service=ppp

*Apr 4 08:30:10: AAA/AUTHOR/FSM: BRI0:1: (0): send AV protocol=unknown

*Apr 4 08:30:10: AAA/AUTHOR/FSM: BRI0:1: (3439943223): Method=RADIUS

*Apr 4 08:30:10: AAA/AUTHOR (3439943223): Post authorization status = PASS_ADD

*Apr 4 08:30:10: AAA/AUTHOR/FSM: BRI0:1: we can start UNKNOWN (0x8207)

%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up

%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up

*Apr 4 08:30:13: AAA/AUTHOR/IPCP: Virtual-Access1: start: her address 10.0.0.1, we want 0.0.0.0

*Apr 4 08:30:13: AAA/AUTHOR/IPCP: Virtual-Access1: (0): user=’Router1’

*Apr 4 08:30:13: AAA/AUTHOR/IPCP: Virtual-Access1: (0): send AV servi*Apr 4 08:30:13: AAA/AUTHOR/IPCP: Virtual-Access1: (0): send AV service=ppp

*Apr 4 08:30:13: AAA/AUTHOR/IPCP: Virtual-Access1: (0): send AV protocol=ip

*Apr 4 08:30:13: AAA/AUTHOR/IPCP: Virtual-Access1: (0): send AV addr*10.0.0.1

*Apr 4 08:30:13: AAA/AUTHOR/IPCP: Virtual-Access1: (3215797579): Method=RADIUS

*Apr 4 08:30:13: AAA/AUTHOR (3215797579): Post authorization status = PASS_ADD

*Apr 4 08:30:13: AAA/AUTHOR/IPCP: Virtual-Access1: Processing AV service=ppp

*Apr 4 08:30:13: AAA/AUTHOR/IPCP: Virtual-Access1: Processing AV protocol=ip

*Apr 4 08:30:13: AAA/AUTHOR/IPCP: Virtual-Access1: Processing AV addr*10.0.0.1

*Apr 4 08:30:13: AAA/AUTHOR/IPCP: Virtual-Access1: Processing AV route=10.1.0.0 255.0.0.0

*Apr 4 08:30:13: AAA/AUTHOR/IPCP: Virtual-Access1: Processing AV route=10.2.0.0 255.0.0.0

*Apr 4 08:30:13: AAA/AUTHOR/IPCP: Virtual-Access1: Processing AV route=10.3.0.0 255.0.0.0

*Apr 4 08:30:13: AAA/AUTHOR/IPCP: Virtual-Access1: Processing AV inacl#5=deny 10.0.0.1

*Apr 4 08:30:13: AAA/AUTHOR/IPCP: Virtual-Access1: authorization succeeded

*Apr 4 08:30:13: AAA/AUTHOR/IPCP: Virtual-Access1: done: her address 10.0.0.1, we want 10.0.0.1

*Apr 4 08:30:13: AAA/AUTHOR/IPCP: Virtual-Access1: authorization succeeded

*Apr 4 08:30:13: AAA/AUTHOR: Virtual-Access1: parse_cmd ‘ip route 10.0.0.0 255.0.0.0 10.0.0.1’ ok (0)

*Apr 4 08:30:13: AAA/AUTHOR: Virtual-Access1: enqueue peruser IP txt=no ip route 10.0.0.0 255.0.0.0 10.0.0.1

*Apr 4 08:30:13: AAA/AUTHOR: Virtual-Access1: parse_cmd ‘ip route 11.0.0.0 255.0.0.0 10.0.0.1’ ok (0)

*Apr 4 08:30:13: AAA/AUTHOR: Virtual-Access1: enqueue peruser IP txt=no ip route 11.0.0.0 255.0.0.0 10.0.0.1

*Apr 4 08:30:13: AAA/AUTHOR: Virtual-Access1: parse_cmd ‘ip route 12.0.0.0 255.0.0.0 10.0.0.1’ ok (0)

*Apr 4 08:30:13: AAA/AUTHOR: Virtual-Access1: enqueue peruser IP txt=no ip route 12.0.0.0 255.0.0.0 10.0.0.1

*Apr 4 08:30:13: AAA/AUTHOR: parse ‘ip access-list standard Virtual-Access1#1’ ok (0)

*Apr 4 08:30:13: AAA/AUTHOR: parse ‘deny 10.0.0.1’ ok (0)

*Apr 4 08:30:13: AAA/AUTHOR: Virtual-Access1: enqueue peruser IP txt=no ip access-list standard Virtual-Access1#1

*Apr 4 08:30:13: VTEMPLATE vaccess1 has a new cloneblk AAA, now it has vtemplate/AAA

*Apr 4 08:30:13: VTEMPLATE ************* CLONE VACCESS1 *****************

*Apr 4 08:30:13: VTEMPLATE Clone from AAA to vaccess1

interface Virtual-Access1

ip access-group Virtual-Access1#1 in

*Apr 4 08:30:13: AAA/AUTHOR: Virtual-Access1: vaccess parse ‘interface Virtual-Access1

ip access-group Virtual-Access1#1 in

‘ ok (0)

*Apr 4 08:30:13: AAA/AUTHOR/FSM: Check for unauthorized mandatory AV’s

*Apr 4 08:30:13: AAA/AUTHOR/FSM: Processing AV service=ppp

*Apr 4 08:30:13: AAA/AUTHOR/FSM: Processing AV protocol=unknown

*Apr 4 08:30:13: AAA/AUTHOR/FSM: succeeded

%ISDN-6-CONNECT: Interface BRI0:1 is now connected to Router1

Router2# show ip access-list

Standard IP access list Virtual-Access1#1 (per-user)

deny 10.0.0.1

Router2# show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR

Gateway of last resort is 172.21.114.129 to network 0.0.0.0

U 10.0.0.0/8 [1/0] via 10.3.0.1

U 10.1.0.0/8 [1/0] via 10.3.0.1

U 10.2.0.0/8 [1/0] via 10.3.0.1

10.3.0.0/8 is subnetted, 1 subnets

C 10.3.0.1 is directly connected, Virtual-Access1

172.21.0.0/16 is subnetted, 1 subnets

C 172.21.114.128 is directly connected, Ethernet0

S* 0.0.0.0/0 [1/0] via 172.21.114.129

Router2# show interfaces virtual-access 1

Virtual-Access1 is up, line protocol is up

Hardware is Virtual Access interface

Interface is unnumbered. Using address of Ethernet0 (172.21.114.132)

MTU 1500 bytes, BW 64 Kbit, DLY 100000 usec, rely 255/255, load 1/255

Encapsulation PPP, loopback not set, keepalive set (10 sec)

DTR is pulsed for 5 seconds on reset

LCP Open, multilink Closed

Open: IPCP, CDP

Last input 5d04h, output never, output hang never

Last clearing of “show interface” counters 00:06:42

Queueing strategy: fifo

Output queue 0/40, 0 drops; input queue 0/75, 0 drops

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

76 packets input, 3658 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

141 packets output, 2909 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

Router2# show ip interface virtual-access 1

Virtual-Access1 is up, line protocol is up

Interface is unnumbered. Using address of Ethernet0 (172.21.114.132)

Broadcast address is 255.255.255.255

Peer address is 10.0.0.1

MTU is 1500 bytes

Helper address is not set

Directed broadcast forwarding is enabled

Outgoing access list is not set

Inbound access list is Virtual-Access1#1

Proxy ARP is enabled

Security level is default

Split horizon is enabled

ICMP redirects are always sent

ICMP unreachables are always sent

ICMP mask replies are never sent

IP fast switching is disabled

Router2# debug ip packet

IP packet debugging is on

Router2#

*Apr 4 08:30:42: IP: s=172.21.114.129 (Ethernet0), d=255.255.255.255, len 186, rcvd 2

*Apr 4 08:30:42: IP: s=10.0.0.1 (Virtual-Access1), d=172.21.114.132, len 104, a*Apr 4 08:30:42: IP: s=10.0.0.1 (Virtual-Access1), d=172.21.114.132, len 104, access denied

*Apr 4 08:30:42: IP: s=172.21.114.132 (local), d=10.0.0.1 (Virtual-Access1), len 4, sending

*Apr 4 08:30:42: IP: s=10.0.0.1 (Virtual-Access1), d=172.21.114.132, len 104, access denied

*Apr 4 08:30:44: IP: s=10.0.0.1 (Virtual-Access1), d=172.21.114.132, len 104, access denied

*Apr 4 08:30:44: IP: s=172.21.114.132 (local), d=10.0.0.1 (Virtual-Access1), len 16, sending

*Apr 4 08:30:44: IP: s=10.0.0.1 (Virtual-Access1), d=172.21.114.132, len 104, access denied

IPX Per-User SAP Filters Using IPXWAN and Virtual Profiles by a Synchronous Interface

The following examples show a remote peer (Router1) configured to dial in to a synchronous interface on a Cisco network access server (Router2), which requests user configuration information from an AAA server (radiusd):

RADIUS User File (Router 1)

Password = "welcome"

User-Service-Type = Framed-User,

Framed-Protocol = PPP,

cisco-avpair = "ipx:sap=101 CYBER-01 40.0000.0000.0001 400 10",

cisco-avpair = "ipx:sap=202 CYBER-02 40.0000.0000.0001 401 10",

cisco-avpair = "ipx:sap=303 CYBER-03 40.0000.0000.0001 402 10",

cisco-avpair = "ipx:sap-fltr-out#20=deny 40 101",

cisco-avpair = "ipx:sap-fltr-out#21=deny 40 202",

cisco-avpair = "ipx:sap-fltr-out#22=permit -1",

cisco-avpair = "ipx:sap-fltr-in#23=permit 30 444",

cisco-avpair = "ipx:sap-fltr-in#23=deny -1"

Current Remote Peer (Router 1) Configuration

hostname Router1

!

enable password lab

!

username Router2 password 7 140017070F0B272E

ip host Router1 172.21.114.131

ip name-server 172.19.2.132

ip name-server 192.168.30.32

ipx routing 0000.0c47.090d

ipx internal-network 30

!

interface Ethernet0

ip address 172.21.114.131 255.255.255.224

!

interface Serial1

no ip address

encapsulation ppp

ipx ipxwan 0 unnumbered peer-Router1

clockrate 4000000

!

ipx sap 444 ZEON-4 30.0000.0000.0001 444 10

ipx sap 555 ZEON-5 30.0000.0000.0001 555 10

ipx sap 666 ZEON-6 30.0000.0000.0001 666 10

!

...

version 12.1

service timestamps debug uptime

!

hostname Router2

!

aaa new-model

aaa authentication ppp default radius

aaa authorization network radius

enable password lab

!

username Router1 password 7 044C0E0A0C2E414B

ip host Router2 172.21.114.133

ip name-server 172.22.30.32

ip name-server 192.168.2.132

ipx routing 0000.0c47.12d3

ipx internal-network 40

!

interface Ethernet0

ip address 172.21.114.133 255.255.255.224

!

interface Virtual-Template1

no ip address

ipx ipxwan 0 unnumbered nas-Router2

no cdp enable

!

interface Serial1

ip unnumbered Ethernet0

encapsulation ppp

ipx ipxwan 0 unnumbered nas-Router2

ppp authentication chap

!

ipx sap 333 DEEP9 40.0000.0000.0001 999 10

!

virtual-profile vtemplate 1

radius-server host 172.21.114.130

radius-server key rad123

RADIUS debug Output

radrecv: Request from host ac157285 code=1, id=23, length=67

Client-Id = 172.21.114.133

Client-Port-Id = 1399128065

User-Name = “Router1”

CHAP-Password = “%”(\012I$\262\352\031\276\024\302\277\225\347z\274”

User-Service-Type = Framed-User

Framed-Protocol = PPP

Sending Ack of id 23 to ac157285 (172.21.114.133)

User-Service-Type = Framed-User

Framed-Protocol = PPP

[Vendor 9] cisco-avpair = “ipx:sap=101 CYBER-01 40.0000.0000.0001 400 10”

[Vendor 9] cisco-avpair = “ipx:sap=202 CYBER-02 40.0000.0000.0001 401 10”

[Vendor 9] cisco-avpair = “ipx:sap=303 CYBER-03 40.0000.0000.0001 402 10”

[Vendor 9] cisco-avpair = “ipx:sap-fltr-out#20=deny1 40 101”

[Vendor 9] cisco-avpair = “ipx:sap-fltr-out#21=deny 40 202”

[Vendor 9] cisco-avpair = “ipx:sap-fltr-out#22=permit -1”

[Vendor 9] cisco-avpair = “ipx:sap-fltr-in#23=permit 30 444”

[Vendor 9] cisco-avpair = “ipx:sap-fltr-in#23=deny -1”

Network Access Server show Command Output

Router2# show ipx servers

Codes: S - Static, P - Periodic, E - EIGRP, N - NLSP, H - Holddown, + = detail

5 Total IPX Servers

Table ordering is based on routing and server info

Type Name Net Address Port Route Hops Itf

s 101 CYBER-01 40.0000.0000.0001:0400 conn 10 Int

s 202 CYBER-02 40.0000.0000.0001:0401 conn 10 Int

s 303 CYBER-03 40.0000.0000.0001:0402 conn 10 Int

S 333 DEEP9 40.0000.0000.0001:0999 conn 10 Int

P 444 ZEON-4 30.0000.0000.0001:0444 7/01 11 Vi1

Router1# show ipx servers

Codes: S - Static, P - Periodic, E - EIGRP, N - NLSP, H - Holddown, + = detail

5 Total IPX Servers

Table ordering is based on routing and server info

Type Name Net Address Port Route Hops Itf

P 303 CYBER-03 40.0000.0000.0001:0402 7/01 11 Se1

P 333 DEEP9 40.0000.0000.0001:0999 7/01 11 Se1

S 444 ZEON-4 30.0000.0000.0001:0444 conn 10 Int

S 555 ZEON-5 30.0000.0000.0001:0555 conn 10 Int

S 666 ZEON-6 30.0000.0000.0001:0666 conn 10 Int

Router2# show ipx access-list

IPX sap access list Virtual-Access1#2

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001-2009 Cisco Systems, Inc. All rights reserved.

Configuring Resource Pool Management

This chapter describes the Cisco Resource Pool Management (RPM) feature. It includes the following main sections:

- RPM Overview

- How to Configure RPM

- Verifying RPM Components

- Troubleshooting RPM

- Configuration Examples for RPM

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature, or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.

, Release 12.2. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

RPM Overview

Cisco RPM enables telephone companies and Internet service providers (ISPs) to share dial resources for wholesale and retail dial network services. With RPM, telcos and ISPs can count, control, and manage dial resources and provide accounting for shared resources when implementing different service-level agreements.

You can configure RPM in a single, standalone Cisco network access server (NAS) by using RPM or, optionally, across multiple NAS stacks by using one or more external Cisco Resource Pool Manager Servers (RPMS).

Cisco RPM gives data network service providers the capability to do the following:

- Have the flexibility to include local retail dial services in the same NAS with the wholesale dial customers.

- Manage customer use of shared resources such as modems or High-Level Data Link Control (HDLC) controllers for data calls.

- Offer advanced wholesale dialup services using a Virtual Private Dialup Network (VPDN) to enterprise accounts and ISPs.

- Deploy Data over Voice Bearer Service (DoVBS).

- Manage call sessions by differentiating dial customers through customer profiles. The customer profile determines where resources are allocated and is based on the incoming Dialed Number Information Service (DNIS) number or Calling Line Identification (CLID).

- Efficiently use resource groups such as modems to offer differing over subscription rates and dial service-level agreements.

Note Ear and Mouth Feature Group B (E&M-FGB) is the only signaling type supported for channel-associated signaling (CAS) on T1 and T3 facilities; R2 is supported for E1 facilities. FG D is not supported. Cisco IOS software collects DNIS digits for the signaling types FGB, PRI, and SS7 and only E&M-FGB and R2 CAS customer profiles are supported. For all other CAS signaling types, use the default DNIS group customer profiles.

Components of Incoming and Outgoing Call Management

Cisco RPM manages both incoming calls and outgoing sessions. Cisco RPM differentiates dial customers through configured customer profiles based on the DNIS and call type determined at the time of an incoming call.

The components of incoming call management in the Cisco RPM are described in the following sections:

- Customer Profile Types

- DNIS Groups

- Call Types

- Resource Groups

- Resource Services

You can use Cisco RPM to answer all calls and differentiate customers by using VPDN profiles and groups. The components of outgoing session management in the Cisco RPM are described in the following sections:

- VPDN Groups

- VPDN Profiles

Note These components of Cisco RPM are enabled after the NAS and other equipment has been initially set up, configured, and verified for proper operation of the dial, PPP, VPDN, and authentication, authorization, and accounting (AAA) segments. Refer to the Cisco IOS documentation for these other segments for installation, configuration, and troubleshooting information before attempting to use RPM.

Configured DNIS groups and resource data can be associated to customer profiles. These customer profiles are selected by the incoming call DNIS number and call type and then used to identify resource allocations based on the associated resource groups and defined resource services.

After the call is answered, customer profiles can also be associated with VPDN groups so the configured VPDN sessions and other data necessary to set up or reject a VPDN session are applied to the answered calls. VPDN group data includes associated domain name or DNIS, IP addresses of endpoints, maximum sessions per endpoint, maximum Multilink PPP (MLP) bundles per VPDN group, maximum links per MLP bundle, and other tunnel information.

Customer Profile Types

There are three types of customer profiles in Cisco RPM, which are described in the following sections:

- Customer Profiles

- Default Customer Profiles

- Backup Customer Profiles

Additionally, you can create a customer profile template and associate it with a customer profile; it is then integrated into the customer profile.

Customer Profiles

A customer profile defines how and when to answer a call. Customer profiles include the following components (see Figure 1):

- Customer profile name and description—Name and description of the customer.

- Session limits—Maximum number of standard sessions.

- Overflow limits—Maximum number of overflow sessions.

- DNIS groups.

- CLID.

- Resource groups.

- Resource services.

- VPDN groups and VPDN profiles.

- Call treatment—Determines how calls that exceed the session and overflow limits are treated.

Figure 1 Components of a Customer Profile

The incoming side of the customer profile determines if the call will be answered using parameters such as DNIS and call type from the assigned DNIS group and session limits. The call is then assigned the appropriate resource within the resource group defined in the customer profile. Each configured customer profile includes a maximum allowed session value and an overflow value. As sessions are started and ended, session counters are incremented and decremented so customer status is kept current. This information is used to monitor the customer resource limit and determine the appropriate call treatment based on the configured session limits.

The outgoing side of the customer profile directs the answered call to the appropriate destination:

Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.

- To a local AAA server of retail dial applications and Internet/intranet access.

- To a tunnel that is established between the NAS or L2TP Access Concentrator (LAC) to a wholesale VPDN home gateway of a dial customer, or L2TP Network Server (LNS) using Layer 2 Forwarding Protocol (L2F) or Layer 2 Tunneling Protocol (L2TP) technology.

Default Customer Profiles

for the DNIS group.

Default customer profiles are used to provide session counting and resource assignment to incoming calls that do not match any of the configured DNIS groups. Although specific resources and DNIS groups can be assigned to customer profiles, default customer profiles allow resource pooling for the calls that do not match the configured DNIS groups or where the DNIS is not provided. Retail dial services and domain-based VPDN use default customer profiles.

When multiple default customer profiles are used, the call type (speech, digital, V.110, or V.120) of the default DNIS group is used to identify which default customer profile to use for an incoming call. At most, four default profiles (one for each call type) can be configured.

Note If default customer profiles are not defined, then calls that do not match a DNIS group in a customer profile are rejected with a “no answer” or “busy” call treatment sent to the switch.

Backup Customer Profiles

Backup customer profiles are customer profiles configured locally on the Cisco NAS and are used to answer calls based on a configured allocation scheme when the link between the Cisco NAS and Cisco RPMS is disabled. See the section “Configuring Customer Profiles Using Backup Customer Profiles” for more information about configuring backup customer profiles.

Customer Profile Template

With RPM, users can also implement wholesale dial services without using VPDN tunnels to complete dial-in calls to destinations of the end customer. This capability is accomplished with components of the AAA groups and the PPP configurations.

The AAA group provides IP addresses of AAA servers for authentication and accounting. The PPP configurations allow users to configure the Cisco IOS PPP feature set on each customer profile. In this current implementation, PPP configuration is based on the following:

- Applicable IP address pool(s) or default local list of IP addresses

- Primary and secondary Domain Name System (DNS) or Windows Internet naming service (WINS)

- Number of links allowed for each call using MLP

Note The AAA and PPP integration applies to a single NAS environment.

To add PPP configurations to a customer profile, you must create a customer profile template. Once you create the template and associate it with a customer profile using the source template command, it is integrated into the customer profile.

The RPM customer profile template for the PPP command set, when used with the Cisco IOS feature, Server Groups Selected by DNIS, presents a strong single NAS solution for providers of wholesale dial services, as follows:

- Call acceptance is determined by the RPM before call answering, using the configured size limits and resource availability.

- The answered call then uses the PPP configuration defined in the template to initiate authentication, obtain an IP address, and select a DNS or WINS that is located at the customer site.

- The same DNIS that was used to choose the customer profile selects the servers for authentication/authorization and accounting that are located at the wholesale customer’s site.

The section “Configuring a Customer Profile Template” later in this chapter describes how to create a customer profile template so that you can configure the Cisco IOS PPP features on a customer profile, but this section does not list the existing PPP command set. For information about the PPP command set, refer to the Cisco IOS Dial Technologies Command Reference.

DNIS Groups

A DNIS group is a configured list of DNIS called party numbers that correspond to the numbers dialed to access particular customers, service offerings, or both. For example, if a customer from phone number 000-1234 calls a number 000-5678, the DNIS provides information on the number dialed—000-5678.

Cisco RPM checks the DNIS number of inbound calls against the configured DNIS groups, as follows:

- If Cisco RPM finds a match, it uses the configured information in the customer profile to which the DNIS group is assigned.

- If Cisco RPM does not find a match, it uses the configured information in the customer profile to which the default DNIS group is assigned.

- The DNIS/call type sequence can be associated only with one customer profile.

CLID Groups

A CLID group is a configured list of CLID calling party numbers. The CLID group specifies a list of numbers to reject if the group is associated with a call discriminator. For example, if a customer from phone number 000-1234 calls a number 000-5678, the CLID provides information on the calling party number—000-1234.

A CLID can be associated with only one CLID group.

Call Types

Call types from calls originating from ISDN, SS7, and CAS (CT1, CT3, and CE1) are used to assign calls to the appropriate resource. Call types for ISDN and SS7 are based on Q.931 bearer capability. Call types for CAS are assigned based on static channel configuration.

Supported call types are as follows:

- Speech

- Digital

- V.110

- V.120

Note Voice over IP, fax over IP, and dial-out calls are not supported in RPM.

Resource Groups

Cisco RPM enables you to maximize the use of available shared resources within a Cisco NAS for various resource allocation schemes to support service-level agreements. Cisco RPM allows you to combine your Cisco NAS resource groups with call types (speech, digital, V.110, and V.120) and optional resource modem services. Resource groups and services are configured for customer profiles and assigned to incoming calls through DNIS groups and call types.

Resource groups have the following characteristics:

- Are configured on the Cisco NAS and applied to a customer profile.

- Represent groupings of similar hardware or firmware that are static and do not change on a per-call basis.

- Can define resources that are port-based or not port-based:

– Port-based resources are identified by physical location, such as a range of port/slot numbers (for example, modems or terminal adapters).

– Non-port-based resources are identified by a single size parameter (for example, HDLC framers or V.120 terminal adapters—V.120 terminal adapters are currently implemented as part of Cisco IOS software).

Resource assignments contain combinations of Cisco NAS resource groups, optional resource modem services, and call types. The NAS resources in resource groups that have not been assigned to a customer profile will not be used.

Note To support ISDN DoVBS, use a DNIS group and a configured customer profile to direct the speech call to the appropriate digital resource. The resource group assigned to this customer profile will be “digital resources” and also have a call type of “speech,” so the call will terminate on an HDLC controller rather than a modem.

Resource Services

.

Table 1 Resource Services

Service

Options

Comments

<300–56000>, any

Must be a V.90 increment.

<300–56000>, any

Must be a V.90 increment.

k56flex, v22bis, v32bis, v34, v90, any

None.

1apm, mn14

This is a hidden command.

mnps, v42bis

This is a hidden command.

VPDN Groups

The VPDN group contains the data required to build a VPDN tunnel from the RPM NAS LAC to the LNS. In the context of RPM, VPDN is authorized by first associating a customer profile with a VPDN group, and second by associating the VPDN group to the DNIS group used for that customer profile. VPDN group data includes the endpoint IP addresses.

Cisco RPM enables you to specify multiple IP endpoints for a VPDN group, as follows:

- If two or more IP endpoints are specified, Cisco RPM uses a load-balancing method to ensure that traffic is distributed across the IP endpoints.

- For DNIS-based VPDN dial service, VPDN groups are assigned to customer profiles based on the incoming DNIS number and the configured DNIS groups.

- For domain-based VPDN dial service, VPDN groups are assigned to the customer profile or the default customer profile with the matching call-type assignment.

- For either DNIS-based or domain-based VPDN dial services, there is a customer profile or default customer profile for the initial resource allocation and customer session limits.

The VPDN group provides call management by allowing limits to be applied to both the number of MLP bundles per tunnel and the number of links per MLP bundle. Limits can also restrict the number of sessions per IP endpoint. If you require more granular control of VPDN counters, use VPDN profiles.

VPDN Profiles

VPDN profiles allow session and overflow limits to be imposed for a particular customer profile. These limits are unrelated to the limits imposed by the customer profile. A customer profile is associated with a VPDN profile. A VPDN profile is associated with a VPDN group. VPDN profiles are required only when these additional counters are required for VPDN usage per customer profile.

Call Treatments

).

Table 2 Call-Treatment Table

Event

Call-Treatment Option

Results

Customer profile not found

No answer (default)

The caller receives rings until the switch eventually times out. Implies that the NAS was appropriate, but resources were unavailable. The caller should try later.

Busy

The switch drops the call from the NAS and sends a busy signal back to the caller. The call is rejected based on not matching a DNIS group/call type and customer profile. Can be used to immediately reject the call and free up the circuit.

Customer profile limits exceeded

Busy

The switch drops the call from the NAS and sends a busy signal back to the caller.

NAS resource not available

Channel not available (default)

The switch sends the call to the next channel in the trunk group. The call can be answered, but the NAS does not have any available resources in the resource groups. Allows the switch to try additional channels until it gets to a different NAS in the same trunk group that has the available resources.

Busy

The switch drops the call from the NAS and sends a busy signal back to the caller. Can be used when the trunk group does not span additional NASes.

Call discrimination match

No answer

The caller receives rings until the switch eventually times out.

Details on RPM Call Processes

On the incoming call management of the customer profile, the following sequence occurs to determine if a call is answered:

is used.

2. The mapped DNIS group is checked against configured call discriminator profiles to confirm if this DNIS group/call-type combination is disallowed. If there is a match, the call is immediately rejected.

3. Once a DNIS group or a default DNIS group is identified, the customer profile associated with that DNIS group and the call type (from the bearer capability for ISDN call, statically configured for CAS calls) is selected. If there is no corresponding customer profile, the call is rejected.

4. The customer profile includes a session limit value and an overflow limit value. If these thresholds are not met, the call is then assigned the appropriate resource defined in the customer profile. If the thresholds are met, the call is rejected.

5. If resources are available from the resource group defined in the customer profile, the call is answered. Otherwise, the call is rejected.

6. As sessions start and end, the session counters increase and decrease, so the customer profile call counters are kept current.

See Figure 2 for a graphical illustration of the RPM call processes.

Figure 2 Incoming Call Management: RPM Functional Description

After the call is answered and if VPDN is enabled, Cisco RPM checks the customer profile for an assigned VPDN group or profile. The outgoing session management of the customer profile directs the answered call to the appropriate destination (see Figure 3), as follows:

Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.

- To a local AAA server of retail dial applications and Internet/intranet access.

- To a tunnel that is established between the NAS or LAC and a wholesale VPDN home gateway from a dial customer or LNS using L2F or L2TP tunneling technology.

Figure 3 Outgoing Call Management: RPM Functional Description for VPDN Profiles and Groups

If a VPDN profile is found, the limits are checked, as follows:

- If the limits have not been exceeded, the VPDN group data associated with that VPDN profile is used to build a VPDN tunnel.

- If the VPDN limits have been exceeded, the call is disconnected.

If a VPDN group is found within the customer profile, the VPDN group data is used to build a VPDN tunnel, as follows:

- If the VPDN group limits (number of multilink bundles, number of links per bundle) have not been exceeded, a VPDN tunnel is built.

- If the limits have been reached, the call is disconnected.

If no VPDN profile is assigned to the customer profile and VPDN is enabled, non-RPM VPDN service is attempted. If the attempt fails, the call is processed as a retail dial service call if local AAA service is available.

Accounting Data

You can generate accounting data for network dial service usage in NAS AAA attribute format.

lists the new fields in the AAA accounting packets.

Table 3 AAA Accounting Records

Accounting Start Record

Accounting Stop Record

VPDN-Group-Active-Sessions

MLP-Session-ID

Data over Voice Bearer Services

DoVBS is a dial service that uses a customer profile and an associated resource group of digital resources to direct data calls with a speech call type to HDLC controllers.

To support ISDN DoVBS, use a DNIS group and a configured customer profile to direct the speech call to the appropriate digital resource.

The resource group assigned to this customer profile will be “digital resources” and will also have a call type of speech, so the call will terminate on an HDLC controller rather than a modem.

Call Discriminator Profiles

The Cisco RPM CLID/DNIS Call Discriminator feature lets you specify a list of calling party numbers to be rejected for inbound calls. This Cisco IOS Release 12.2 CLID/DNIS call screening feature expands previous call screening features in Cisco RPM. CLID/DNIS call screening provides an additional way to screen calls on the basis of CLID/DNIS for both local and remote RPM.

Cisco RPM CLID/DNIS Call Discriminator profiles enable you to process calls differently on the basis of the call type and CLID combination. Resource pool management offers a call discrimination feature that rejects calls on the basis of a CLID group and a call type filter. When a call arrives at the NAS, the CLID and the call type are matched against a table of disallowed calls. If the CLID and call type match entries in this table, the call is rejected before it is assigned Cisco NAS resources or before any other Cisco RPM processing occurs. This is called precall screening.

Precall screening decides whether the call is allowed to be processed. You can use the following types of discriminators to execute precall screening:

- ISDN discriminator —Accepts a call if the calling number matches a number in a group of configured numbers (ISDN group). This is also called white box screening. If you configure an ISDN group, only the calling numbers specified in the group are accepted.

- DNIS discriminator—Accepts a call if the called party number matches a number in a group of configured numbers (DNIS group). If you set up a DNIS group, only the called party numbers in the group are accepted. DNIS gives you information about the called party.

- Cisco RPM CLID/DNIS discriminator—Rejects a call if the calling number matches a number in a group of configured numbers (CLID/DNIS group). This is also called black box screening.

If you configure a discriminator with a CLID group, the calling party numbers specified in the group are rejected. CLID gives you information about the caller.

Similarly, if you configure a discriminator with a DNIS group, the called party numbers specified in the group are rejected.

for more information about call preauthorization.

In Cisco RPM CLID/DNIS screening, the discriminator can be a CLID discriminator, a DNIS discriminator, or a discriminator that screens on both the CLID and DNIS. The resulting discrimination logic is:

- If a discriminator contains just DNIS groups, it is a DNIS discriminator that ignores CLID. The DNIS discriminator blocks the call if the called number is in a DNIS group, which the call type references.

- If a discriminator contains just CLID groups, it is a CLID discriminator that ignores DNIS. The CLID discriminator blocks the call if the calling number is in a CLID group, which the call type references.

- If a discriminator contains both CLID and DNIS groups, it is a logical AND discriminator. It blocks the call if the calling number and called number are in the CLID or DNIS group, and the call type references the corresponding discriminator.

Figure 4 shows how call discrimination can be used to restrict a specific DNIS group to only modem calls by creating call discrimination settings for the DNIS group and the other supported call types (digital, V.110, and V.120).

Figure 4 Call Discrimination

Incoming Call Preauthentication

With ISDN PRI or channel-associated signaling (CAS), information about an incoming call is available to the NAS before the call is connected. The available call information includes:

- The DNIS, also referred to as the called number

- The CLID, also referred to as the calling number

- The call type, also referred to as the bearer capability

The Preauthentication with ISDN PRI and Channel-Associated Signalling feature introduced in Cisco IOS Release 12.2 allows a Cisco NAS to decide—on the basis of the DNIS number, the CLID number, or the call type—whether to connect an incoming call.

When an incoming call arrives from the public network switch, but before it is connected, this feature enables the NAS to send the DNIS number, CLID number, and call type to a RADIUS server for authorization. If the server authorizes the call, the NAS accepts the call. If the server does not authorize the call, the NAS sends a disconnect message to the public network switch to reject the call.

The Preauthentication with ISDN PRI and Channel-Associated Signalling feature offers the following benefits:

- With ISDN PRI, it enables user authentication and authorization before a call is answered. With CAS, the call must be answered; however, the call can be dropped if preauthentication fails.

- It enables service providers to better manage ports using their existing RADIUS solutions.

- Coupled with a preauthentication RADIUS server application, it enables service providers to efficiently manage the use of shared resources to offer differing service-level agreements.

.

RPM Standalone Network Access Server

A single NAS using Cisco RPM can provide the following:

- Wholesale VPDN dial service to corporate customers

- Direct remote services

- Retail dial service to end users

Figure 5 and Figure 6 show multiple connections to a Cisco AS5300 NAS. Incoming calls to the NAS can use ISDN PRI signaling, CAS, or the SS7 signaling protocol. Figure 5 shows incoming calls that are authenticated locally for retail dial services or forwarded through VPDN tunnels for wholesale dial services.

Note This implementation does not use Cisco RPM CLID/DNIS Call Discriminator Feature. If you are not using Cisco RPMS and you have more than one Cisco NAS, you must manually configure each NAS by using Cisco IOS commands. Resource usage information is not shared between NASes.

Figure 5 Retail Dial Service Using RPM

Figure 6 shows a method of implementing wholesale dial services without using VPDN tunnels by creating individual customer profiles that consist of AAA groups and PPP configurations. The AAA groups provide IP addresses of AAA servers for authentication and accounting. The PPP configurations enable you to set different PPP parameter values on each customer profile. A customer profile typically includes the following PPP parameters:

- Applicable IP address pools or a default local list of IP addresses

- Primary and secondary DNS or WINS

- Authentication method such as the Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), or Microsoft CHAP Version 1 (MS-CHAP)

- Number of links allowed for each call using Multilink PPP

Note The AAA and PPP integration applies to a single NAS environment; the external RPMS solution is not supported.

Figure 6 Resource Pool Management with Direct Remote Services

Call Processing

For call processing, incoming calls are matched to a DNIS group and the customer profile associated with that DNIS group. If a match is found, the customer profile session and overflow limits are applied and if available, the required resources are allocated. If a DNIS group is not found, the customer profile associated with the default DNIS group is used. The call is rejected if a customer profile using the default DNIS group cannot be found.

After the call is answered and if VPDN is enabled, the Cisco RPM checks the customer profile for an assigned VPDN group or profile. If a VPDN group is found, Cisco RPM authorizes VPDN by matching the group domain name or DNIS with the incoming call. If a match is found, VPDN profile session and overflow limits are applied, and, if the limits are not exceeded, tunnel negotiation begins. If the VPDN limits are exceeded, the call is disconnected.

If no VPDN profile is assigned to the customer profile and VPDN is enabled, non-RPM VPDN service will be attempted. If it fails, the call is processed as a retail dial service call if local AAA service is available.

Base Session and Overflow Session Limits

Cisco RPM enables you to set base and overflow session limits in each customer profile. The base session limit determines the maximum number of nonoverflow sessions supported for a customer profile. When the session limit is reached, if overflow sessions are not enabled, any new calls are rejected. If overflow sessions are enabled, new sessions up to the session overflow limit are processed and marked as overflow for call handling and accounting.

summarizes the effects of session and session overflow limits.

Enabling overflow sessions is useful for allocating extra sessions for preferred customers at premium rates. Overflow sessions can also be useful for encouraging customers to adequately forecast bandwidth usage or for special events when normal session usage is exceeded. For example, if a customer is having a corporate-wide program and many people are expected to request remote access, you could enable many overflow sessions and charge a premium rate for the excess bandwidth requirements.

Note An overflow call is a call received while the session limit is exceeded and is in an overflow state. When a call is identified as an overflow call, the call maintains the overflow status throughout its duration, even if the number of current sessions returns below the session limit.

Table 4 Effects of Session Limit and Session Overflow Limit Settings Combinations

Base Session Limit

Session Overflow Limit

Call Handling

0

0

Reject all calls.

10

0

Accept up to 10 sessions.

10

10

Accept up to 20 sessions and mark sessions 11 to 20 as overflow sessions.

0

10

Accept up to 10 sessions and mark sessions 1 to 10 as overflow.

All

0

Accept all calls.

0

All

Accept all calls and mark all calls as overflow.

VPDN Session and Overflow Session Limits

Cisco RPM enables you to configure base and overflow session limits per VPDN profile for managing VPDN sessions.

Note The VDPN session and session overflow limits are independent of the limits set in the customer profiles.

The base VPDN session limit determines the maximum number of nonoverflow sessions supported for a VPDN profile. When the VPDN session limit is reached, if overflow sessions are not enabled, any new VPDN calls using the VPDN profile sessions are rejected. If overflow sessions are enabled, new sessions up to the session overflow limit are processed and marked as overflow for VPDN accounting.

The VPDN session overflow limit determines the number of sessions above the session limit allowed in the VPDN group. If the session overflow limit is greater than zero, overflow sessions are enabled and the maximum number of allowed sessions is the session limit plus the session overflow limit. While the session overflow limit has been reached, any new calls are rejected.

Enabling VPDN overflow sessions is useful for allocating extra sessions for preferred customers at premium rates. Overflow sessions are also useful for encouraging customers to adequately forecast bandwidth usage or for special events when normal session usage is exceeded. For example, if a customer is having a corporate-wide program and many people are expected to request remote access, you could enable many overflow sessions and charge a premium rate for the extra bandwidth requirements.

VPDN MLP Bundle and Links-per-Bundle Limits

To ensure that resources are not consumed by a few users with MLP connections, Cisco RPM also enables you to specify the maximum number of MLP bundles that can open in a VPDN group. In addition, you can specify the maximum number of links for each MLP bundle.

For example, if standard ISDN users access the VPDN profile, limit this setting to two links per bundle. If video conferencing is used, increase this setting to accommodate the necessary bandwidth (usually six links). These limits have no overflow option and are configured under the VPDN group component.

VPDN Tunnel Limits

For increased VPDN tunnel management, Cisco RPM enables you to set an IP endpoint session limit for each IP endpoint. IP endpoints are configured for VPDN groups.

Figure 7 and Figure 8 show logical flowcharts of RPM call processing for a standalone NAS with and without the RPM Direct Remote Services feature.

Figure 7 RPM Call-Processing Flowchart for a Standalone Network Access Server

Figure 8 Flowchart for a Standalone Network Access Server with RPM Direct Remote Services

RPM Using the Cisco RPMS

Figure 9 shows a typical resource pooling network scenario using RPMS.

Figure 9 RPM Scenario Using RPMS

Resource Manager Protocol

Resource Manager Protocol (RMP) is a robust, recoverable protocol used for communication between the Cisco RPMS and the NAS. Each NAS client uses RMP to communicate resource management requests to the Cisco RPMS server. RPMS also periodically polls the NAS clients to query their current call information or address error conditions when they occur. RMP also allows for protocol attributes that make it extensible and enable support for customer billing requirements.

Figure 10 shows the relationship of Cisco RPM CLID/DNIS Call Discriminator Feature and RMP.

Figure 10 Cisco RPM CLID/DNIS Call Discriminator Feature and RMP

Note RMP must be enabled on all NASes that communicate with the Cisco RPM CLID/DNIS Call Discriminator Feature.

Direct Remote Services

Direct remote services is an enhancement to Cisco RPM implemented in Cisco IOS Release 12.0(7)T that enables service providers to implement wholesale dial services without using VPDN tunnels. A customer profile that has been preconfigured with a PPP template to define the unique PPP services for the wholesale dial customer is selected by the incoming DNIS and call type. At the same time, the DNIS is used to select AAA server groups for authentication/authorization and for accounting for the customer.

PPP Common Configuration Architecture (CCA) is the new component of the RPM customer profile that enables direct remote services. The full PPP command set available in Cisco IOS software is configurable per customer profile for wholesale dial applications. A customer profile typically includes the following PPP parameters:

- Local or named IP address pools

- Primary and secondary DNS or WINS addresses

- Authentication method (PAP, CHAP, MS-CHAP)

- Multilink PPP links per bundle limits

The AAA session information is selected by the incoming DNIS. AAA server lists provide the IP addresses of AAA servers for authentication, authorization, and accounting in the wholesale local network of the customer. The server lists for both authentication and authorization and for accounting contain the server addresses, AAA server type, timeout, retransmission, and keys per server.

When direct remote services is implemented on a Cisco NAS, the following sequence occurs:

1. The NAS sends an authorization request packet to the AAA server by using the authentication method (PAP, CHAP, MSCHAP) that has been configured through PPP.

2. The AAA server accepts the authorization request and returns one of the following items to the NAS:

– A specific IP address

– An IP address pool name

– Nothing

3. Depending on the response from the AAA server, the NAS assigns one of the following items to the user through the DNS/WINS:

– The IP address returned by the AAA server

– An IP address randomly assigned from the named IP address pool

– An IP address from a pool specified in the customer profile template

Note If the AAA server sends back to the NAS a named IP address pool and that name does not exist on the NAS, the request for service is denied. If the AAA server does not send anything back to the NAS and there is an IP address pool name configured in the customer profile template, an address from that pool is used for the session.

RPM Process with RPMS and SS7

Additional Information About Cisco RPM

For more information about Cisco RPM, see the following documents:

- AAA Server Group

- Cisco Access VPN Solutions Using Tunneling Technology

- Cisco AS5200 Universal Access Server Software Configuration Guide

- Cisco AS5300 Software Configuration Guide

- Cisco AS5800 Access Server Software ICG

- Cisco Resource Pool Manager Server Configuration Guide

- Cisco Resource Pool Manager Server Installation Guide

- Cisco Resource Pool Manager Server Solutions Guide

- Dial Solutions Quick Configuration Guide

- RADIUS Multiple UDP Ports Support

- Redundant Link Manager

- Release Notes for Cisco Resource Pool Manager Server Release 1.0

- Resource Pool Management

- Resource Pool Management with Direct Remote Services

- Resource Pool Manager Customer Profile Template

- Selecting AAA Server Groups Based on DNIS

- SS7 Continuity Testing for Network Access Servers

- SS7 Dial Solution System Integration

How to Configure RPM

Read and comply with the following restrictions and prerequisites before beginning RPM configuration:

- RPM is supported on Cisco AS5300, Cisco AS5400, and Cisco AS5800 Universal Access Servers

- Modem pooling and RPM are not compatible.

- The Cisco RPM CLID/DNIS Call Discriminator Feature must have Cisco RPM configured.

- CLID screening is not available to channel-associated signaling (CAS) interrupt level calls.

- Cisco RPM requires the NPE 300 processor when implemented on the Cisco AS5800.

- For Cisco AS5200 and Cisco AS5300 access servers, Cisco IOS Release 12.0(4)XI1 or later releases must be running on the NAS.

- For Cisco AS5800, Cisco IOS Release 12.0(5)T or later releases must be running on the NAS.

- A minimum of 64 MB must be available on the DMM cards.

- The RPM application requires an NPE 300.

- For call discriminator profiles, the Cisco AS5300, Cisco AS5400, or Cisco AS5800 Universal Access Servers require a minimum of 16 MB Flash memory and 128 MB DRAM memory, and need to be configured for VoIP as an H.323-compliant gateway.

The following tasks must be performed before configuring RPM:

- Accomplish initial configuration as described in the appropriate Universal Access Server Software Configuration Guide . Perform the following tasks as required.

– Set your local AAA

– Define your TACACS+ server for RPM

– Define AAA accounting

– Ensure PPP connectivity

– Ensure VPDN connectivity

for more information.

To configure your NAS for RPM, perform the following tasks:

- Enabling RPM (Required)

- Configuring DNIS Groups (As required)

- Creating CLID Groups (As required)

- Configuring Discriminator Profiles (As required)

- Configuring Resource Groups (As required)

- Configuring Service Profiles (As required)

- Configuring Customer Profiles (As required)

- Configuring a Customer Profile Template (As required)

- Placing the Template in the Customer Profile (As required)

- Configuring AAA Server Groups (As required)

- Configuring VPDN Profiles (As required)

- Configuring VPDN Groups (As required)

- Counting VPDN Sessions by Using VPDN Profiles (As required)

- Limiting the Number of MLP Bundles in VPDN Groups (As required)

- Configuring Switched 56 over CT1 and RBS (As required)

See the section “Troubleshooting RPM” later in this chapter for troubleshooting tips. See the section “Configuration Examples for RPM” at the end of this chapter for examples of how to configure RPM in your network.

Enabling RPM

To enable RPM, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Turns on RPM.

Step 2

Creates a resource group for resource management.

Step 3

Sets up the signal sent back to the telco switch in response to incoming calls.

Step 4

Specifies which protocol to use for resource management.

Note If you have an RPMS, you need not define VPDN groups/profiles, customer profiles, or DNIS groups on the NAS; you need only define resource groups. Configure the remaining items by using the RPMS system.

Configuring DNIS Groups

This configuration task is optional.

To configure DNIS groups, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Creates a DNIS group. The name you specify in this step must match the name entered when configuring the customer profile.

Step 2

}

Statically sets the call-type override for incoming CAS calls.

Step 3

Enters DNIS numbers to be used in the customer profile. (Wildcards can be used.)

For default DNIS service, no DNIS group configuration is required. The following characteristics and restrictions apply to DNIS group configuration:

- Each DNIS group/call-type combination can apply to only one customer profile.

- You can use up to four default DNIS groups (one for each call type).

- You must statically configure CAS call types.

- You can use x, X or . as wildcards within each DNIS number.

Creating CLID Groups

You can add multiple CLID groups to a discriminator profile. You can organize CLID numbers for a customer or service type into a CLID group. Add all CLID numbers into one CLID group, or subdivide the CLID numbers using criteria such as call type, geographical location, or division. To create CLID groups, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

for information on configuring customer profiles.

Step 2

as wildcards within each CLID number. The CLID screening feature rejects this number if it matches the CLID of an incoming call.

Configuring Discriminator Profiles

Discriminator profiles enable you to process calls differently on the basis of the call type and CLID/DNIS combination. The “Call Discriminator Profiles” section earlier in this chapter describes the different types of discriminator profiles that you can create.

To configure discriminator profiles for RPM implementation, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Creates a call discriminator profile and assigns it a name of up to 23 characters.

Step 2

}

Specifies the type of calls you want to block. The NAS will not answer the call-type you specify.

Step 3

}

e.

After a CLID group is associated with a call type in a discriminator, it cannot be used in any other discriminator.

Step 4

}

e.

After a DNIS group is associated with a call type in a discriminator, it cannot be used in any other discriminator.

To verify discriminator profile settings, use the following commands:

command to verify the call discriminator profiles that you configured.

command without including a call discriminator name, a list of all current call discriminator profiles appears.

command, the number of calls rejected by the selected call discriminator appears.

Router# show resource-pool discriminator

List of Call Discriminator Profiles:

deny_CLID

Router# show resource-pool discriminator deny_CLID

1 calls rejected

command to display general diagnostic information for interfaces configured for the dialer.

Router# show dialer [interface] type number

Configuring Resource Groups

To configure resource groups, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Creates a resource group and assign it a name of up to 23 characters.

Step 2

}

Associates a range of modems or other physical resources with this resource group:

- For port-based resources, use the physical locations of the resources.

- For non-port-based resources, use a single integer limit. Specify the maximum number of simultaneous connections supported by the resource group. Up to 192 connections may be supported, depending on the hardware configuration of the access server.

For external Cisco RPMS environments, configure resource groups on the NAS before defining them on external RPMS servers.

For standalone NAS environments, first configure resource groups before using them in customer profiles.

Resource groups can apply to multiple customer profiles.

Note You can separate physical resources into groups. However, do not put heterogeneous resources in the same group. Do not put MICA technologies modems in the same group as Microcom modems. Do not put modems and HDLC controllers in the same resource group. Do not configure the port and limit command parameters in the same resource group.

Configuring Service Profiles

To configure service profiles, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Creates a service profile and assign it a name of up to 23 characters.

Step 2

Router(config-service-profil)# modem min-speed {speed | any} max-speed {speed | any [modulation value]}

is 300 to 56000 bits per second.

Service profiles are used to configure modem service parameters for Nextport and MICA technologies modems, and support speech, digital, V.110, and V.120 call types. Error-correction and compression are hidden parameters that may be included in a service profile.

Configuring Customer Profiles

To configure customer profiles, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Creates a customer profile.

Step 2

}

Includes a group of DNIS numbers in the customer profile.

Step 3

}

Specifies the base size usage limit.

Step 4

}

Specifies the oversize size usage limit.

Step 5

]

Assigns resources and supported call types to the customer profile.

Customer profiles are used so that service providers can assign different service characteristics to different customers. Note the following characteristics of customer profiles:

- Multiple resources of the same call type are used sequentially.

- The limits imposed are per customer (DNIS)—not per resource.

- A digital resource with a call type of speech allows for Data over Speech Bearer Service (DoSBS).

Configuring Default Customer Profiles

for the DNIS group:

Command

Purpose

Step 1

Assigns a name to the default customer profile.

Step 2

Assigns the default DNIS group to the customer profile. This sets up the customer profile such that it will use the default DNIS configuration, which is automatically set on the NAS.

The rest of the customer profile is configured as shown in the previous section “Configuring Customer Profiles.”

Configuring Customer Profiles Using Backup Customer Profiles

Backup customer profiles are customer profiles configured locally on the Cisco NAS and are used to answer calls on the basis of a configured allocation scheme when the link between the Cisco NAS and Cisco RPMS is disabled.

To enable the backup feature, you need to have already configured the following on the router:

- The resource-pool aaa protocol group name local command.

- All customer profiles and DNIS groups on the NAS.

The backup customer profile can contain all of the elements defined in a standard customer profile, including base size or overflow parameters. However, when the connection between the Cisco NAS and Cisco RPMS is unavailable, session counting and session limits are not applied to incoming calls. Also, after the connection is reestablished, there is no synchronization of call counters between the Cisco NAS and Cisco RPMS.

Configuring Customer Profiles for Using DoVBS

To configure customer profiles for using DoVBS, use the following commands beginning in global configuration command mode:

Command

Purpose

Step 1

Assigns a name to a customer profile.

Step 2

Assigns a DNIS group to the customer profile. DNIS numbers are assigned as shown in the previous section.

Step 3

}

Specifies the VPDN base size usage limit.

Step 4

}

Specifies the VPDN overflow size usage limit.

Step 5

]

Specifies resource names to use within the customer profile.

To support ISDN DoVBS, use a DNIS group and a configured customer profile to direct the speech call to the appropriate digital resource. The DNIS group assigned to the customer profile should have a call type of speech. The resource group assigned to this customer profile will be digital resources and also have a call type of speech, so the call will terminate on an HDLC controller rather than a modem.

See the section “Customer Profile Configuration for DoVBS Example” at the end of this chapter for a configuration example.

Configuring a Customer Profile Template

Customer profile templates provide a way to keep each unique situation for a customer separate for both security and accountability. This is an optional configuration task.

To configure a template and place it in a customer profile, ensure that all basic configuration tasks and the RPM configuration tasks have been completed and verified before attempting to configure the customer profile templates.

To add PPP configurations to a customer profile, create a customer profile template. Once you create the template and associate it with a customer profile by using the source template command, it is integrated into the customer profile.

To configure a template in RPM, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

name

Creates a customer profile template and assign a unique name that relates to the customer that will be receiving it.

Note Steps 2, 3, and 4 are optional. Enter multilink, peer, and ppp commands appropriate to the application requirements of the customer.

Step 2

(Optional) Specifies that the customer profile to which this template is attached will use a local IP address pool with the specified name.

Step 3

(Optional) Sets the PPP link authentication method.

Step 4

(Optional) Enables Multilink PPP for this customer profile.

Step 5

Exits from template configuration mode; returns to global configuration mode.

Step 6

Enters customer profile configuration mode for the customer to which you wish to assign this template.

Step 7

Attaches the customer profile template you have just configured to the customer profile.

Typical Template Configuration

The following example shows a typical template configuration:

template Word

multilink {max-fragments frag-num | max-links num | min-links num}

peer match aaa-pools

peer default ip address {pool pool-name1 [pool-name2] | dhcp}

ppp ipcp {dns | wins} A.B.C.D [W.X.Y.Z]

resource-pool profile customer WORD

source template Word

aaa group-configuration aaa-group-name

template acme_direct

peer default ip address pool tahoe

ppp authentication chap isdn-users

ppp multilink

Verifying Template Configuration

To verify your template configuration, perform the following steps:

Step 1 Enter the show running-config EXEC command (where the template name is “PPP1”):

Router#

Router# show running-config begin template

.

.

.

template PPP1

peer default ip address pool pool1 pool2

ppp ipcp dns 10.1.1.1 10.1.1.2

ppp ipcp wins 10.1.1.3 10.1.1.4

ppp multilink max-links 2

.

.

.

Step 2 Ensure that your template appears in the configuration file.

Placing the Template in the Customer Profile

To place your template in the customer profile, use the following commands beginning in global configuration command mode:

Command

Purpose

Step 1

Router(config)# resource-pool profile customer name

Assigns a name to a customer profile.

Step 2

Router(config-customer-pr)# source template

Associates the template with the customer profile.

To verify the placement of your template in the customer profile, perform the following steps:

Step 1 Enter the show resource-pool customer EXEC command:

Router# show resource-pool customer

List of Customer Profiles:

CP1

CP2

Step 2 Look at the list of customer profiles and make sure that your profile appears in the list.

Step 3 To verify a particular customer profile configuration, enter the show resource-pool customer name EXEC command (where the customer profile name is “CP1”):

Router# show resource-pool customer CP1

97 active connections

120 calls accepted

210 max number of simultaneous connections

50 calls rejected due to profile limits

0 calls rejected due to resource unavailable

90 minutes spent with max connections

5 overflow connections

2 overflow states entered

0 overflow connections rejected

0 minutes spent in overflow

13134 minutes since last clear command

Configuring AAA Server Groups

To configure AAA server groups, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Enables AAA on the NAS.

Step 2

or

Set the authentication and encryption key used for all RADIUS or TACACS+ communications between the NAS and the RADIUS or TACACS+ daemon.

Step 3

]

or

Specifies the host name or IP address of the server host before configuring the AAA server group. You can also specify the UDP destination ports for authentication and for accounting.

Step 4

Selects the AAA server type you want to place into a server group and assign a server group name.

Step 5

Specifies the IP address of the selected server type. This must be the same IP address that was assigned to the server host in Step 3.

Step 6

Returns to global configuration mode.

Step 7

Enters customer profile configuration mode for the customer to which you wish to assign this AAA server group.

Step 8

Associates this AAA server group (named in Step 4) with the customer profile named in Step 7.

AAA server groups are lists of AAA server hosts of a particular type. The Cisco RPM currently supports RADIUS and TACACS+ server hosts. A AAA server group lists the IP addresses of the selected server hosts.

You can use a AAA server group to define a distinct list of AAA server hosts and apply this list to the Cisco RPM application. Note that the AAA server group feature works only when the server hosts in a group are of the same type.

Configuring VPDN Profiles

A VPDN profile is required only if you want to impose limits on the VPDN tunnel that are separate from the customer limits.

To configure VPDN profiles, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Creates a VPDN profile and assigns it a profile name

Step 2

}

.

Step 3

}

.

Step 4

Returns to global configuration mode.

Step 5

Enters customer profile configuration mode for the customer to which you wish to assign this VPDN group.

Step 6

or

Attaches the VPDN profile you have just configured to the customer profile to which it belongs, or, if the limits imposed by the VPDN profile are not required, attaches VPDN group instead (see the section “Configuring VPDN Groups” later in this chapter).

Configuring VPDN Groups

To configure VPDN groups, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Enables VPDN sessions on the NAS.

Step 2

Creates a VPDN group and assigns it a unique name. Each VPDN group can have multiple endpoints (HGW/LNSs).

Step 3

}

Specifies the tunneling protocol to be used to reach the remote peer defined by a specific IP address if a dial-in request is received for the specified domain name or DNIS number. The IP address that qualifies the session is automatically generated and need not be entered again.
was removed in Cisco IOS software.

Step 4

}

Specifies the maximum number of bundles and links for all multilink users in the VPDN group. The range for both bundles and links is 0 to 32767. In general, each user requires one bundle.

Step 5

]

keyword limits the number of simultaneous sessions that are sent to the remote endpoint (HGW/LNS). This limit can be 0 to 32767 sessions.

Step 6

]

Sets up a backup HGW/LNS router. The number of sessions per backup can be limited. The priority number can be 2 to 32767. The highest priority is 2, which is the first HGW/LNS router to receive backup traffic. The lowest priority, which is the default, is 32767.

Step 7

Returns to global configuration mode.

Step 8

or

Enters either VPDN profile configuration mode or customer profile configuration mode, depending on whether you want to allow VPDN connections for a customer profile, or allow combined session counting on all of the VPDN sessions within a VPDN profile.

Step 9

or

Attaches the VPDN group to either the VPDN profile or the customer profile specified in Step 8.

A VPDN group consists of VPDN sessions that are combined and placed into a customer profile or a VPDN profile. Note the following characteristics of VPDN groups:

- The dnis-group-name argument is required to authorize the VPDN group with RPM.

- A VPDN group placed in a customer profile allows VPDN connections for the customer using that profile.

- A VPDN group placed in a VPDN profile allows the session limits configured for that profile to apply to all of the VPDN sessions within that VPDN group.

- VPDN data includes an associated domain name or DNIS, an endpoint IP address, the maximum number of MLP bundles, and the maximum number of links per MLP bundle; this data can optionally be located on a AAA server.

See the sections “VPDN Configuration Example” and “VPDN Load Sharing and Backing Up Between Multiple HGW/LNSs Example” at the end of this chapter for examples of using VPDN with RPM.

Counting VPDN Sessions by Using VPDN Profiles

Session counting is provided for each VPDN profile. One session is brought up each time a remote client dials into a HGW/LNS router by using the NAS/LAC. Sessions are counted by using VPDN profiles. If you do not want to count the number of VPDN sessions, do not set up any VPDN profiles. VPDN profiles count sessions in one or more VPDN groups.

To configure VPDN profile session counting, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Creates a VPDN profile.

Step 2

Associates a VPDN group to the VPDN profile. VPDN sessions done within this VPDN group will be counted by the VPDN profile.

Step 3

Links the VPDN group to a customer profile.

Step 4

Router#

Returns to EXEC mode to perform verification steps.

command. In this example, two different VPDN groups are configured under two different customer profiles:

Router# show resource-pool vpdn group

List of VPDN Groups under Customer Profiles

Customer Profile customer1:customer1-vpdng

Customer Profile customer2:customer2-vpdng

List of VPDN Groups under VPDN Profiles

command. This example contains one domain name, two DNIS called groups, and two endpoints:

Router# show resource-pool vpdn group customer2-vpdng

VPDN Group customer2-vpdng found under Customer Profiles: customer2

Tunnel (L2TP)

------

dnis:cg1

dnis:cg2

dnis:jan

Endpoint Session Limit Priority Active Sessions Status Reserved Sessions

-------- ------------- -------- --------------- ------ -----------------

172.21.9.67 * 1 0 OK -

10.1.1.1 * 2 0 OK -

--------------- ------------- --------------- -----------------

Total * 0 0

command, as follows:

Router# show resource-pool vpdn profile ?

WORD VPDN profile name

<cr>

Router# show resource-pool vpdn profile customer1-profile

0 active connections

0 max number of simultaneous connections

0 calls rejected due to profile limits

0 calls rejected due to resource unavailable

0 overflow connections

0 overflow states entered

0 overflow connections rejected

1435 minutes since last clear command

Note Use the debug vpdn event command to troubleshoot VPDN profile limits, session limits, and MLP connections. First, enable this command; then, send a call into the access server. Interpret the debug output and make configuration changes as needed.

command:

Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.

Router# debug vpdn l2x ?

error VPDN Protocol errors

event VPDN event

l2tp-sequencing L2TP sequencing

l2x-data L2F/L2TP data packets

l2x-errors L2F/L2TP protocol errors

l2x-events L2F/L2TP protocol events

l2x-packets L2F/L2TP control packets

packet VPDN packet

Limiting the Number of MLP Bundles in VPDN Groups

Cisco IOS software enables you to limit the number of MLP bundles and links supported for each VPDN group. A bundle name consists of a username endpoint discriminator (for example, an IP address or phone number) sent during LCP negotiation.

To limit the number of MLP bundles in VPDN groups, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Creates a VPDN group.

Step 2

}

Limits the number of MLP bundles per VPDN group and links per bundle.1 These settings limit the number of users that can multilink.

1.Both the NAS/LAC and the HGW/LNS router must be configured to support multilink before a client can use multilink to connect to a HGW/LNS.

1.Both the NAS/LAC and the HGW/LNS router must be configured to support multilink before a client can use multilink to connect to a HGW/LNS.

command output for verifying MLP bundle limits:

Router# show vpdn multilink

Multilink Bundle Name VPDN Group Active links Reserved links Bundle/Link Limit

--------------------- ---------- ------------ -------------- -----------------

twv@anycompany.com vgdnis 0 0 */*

Note Use the debug vpdn event and debug resource-pooling commands to troubleshoot VPDN profile limits, session limits, and MLP connections. First, enable this command; then, send a call into the access server. Interpret the debug output and make configuration changes as needed.

Configuring Switched 56 over CT1 and RBS

To configure switched 56 over CT1 and RBS, use the following commands beginning in global configuration mode. Perform this task on the Cisco AS5200 and Cisco AS5300 access servers only.

Command

Purpose

Step 1

Specifies a controller and begins controller configuration mode.

Step 2

}

Creates a CAS group and assigns time slots.

Step 3

}

Specifies framing.

Step 4

}

Enters the line code.

Step 5

Returns to global configuration mode.

Step 6

Creates a dialer called group.

Step 7

Assigns a call type as digital (switch 56).

Step 8

Returns to global configuration mode.

Step 9

Router(config-if)#

command was issued.

This command also enters interface configuration mode, where you configure the core protocol characteristics for the serial interface.

command as follows:

Router# show dialer dnis group

List of DNIS Groups:

default

mdm_grp1

Router# show dialer dnis group mdm_grp1

Called Number:2001

0 total connections

0 peak connections

0 calltype mismatches

Called Number:2002

0 total connections

0 peak connections

0 calltype mismatches

Called Number:2003

0 total connections

0 peak connections

0 calltype mismatches

Called Number:2004

0 total connections

0 peak connections

0 calltype mismatches

.

.

.

Router# show dialer dnis number

List of Numbers:

default

2001

2002

2003

2004

.

.

.

Verifying RPM Components

The following sections provide call-counter and call-detail output for the different RPM components:

- Verifying Current Calls

- Verifying Call Counters for a Customer Profile

- Clearing Call Counters

- Verifying Call Counters for a Discriminator Profile

- Verifying Call Counters for a Resource Group

- Verifying Call Counters for a DNIS Group

- Verifying Call Counters for a VPDN Profile

- Verifying Load Sharing and Backup

Verifying Current Calls

command shows the details for all current calls, including the customer profile and resource group, and the matched DNIS group:

Router# show resource-pool call

Shelf 0, slot 0, port 0, channel 15, state RM_RPM_RES_ALLOCATED

Customer profile ACME, resource group isdn-ports

DNIS number 301001

Shelf 0, slot 0, port 0, channel 14, state RM_RPM_RES_ALLOCATED

Customer profile ACME, resource group isdn-ports

DNIS number 301001

Shelf 0, slot 0, port 0, channel 11, state RM_RPM_RES_ALLOCATED

Customer profile ACME, resource group MICA-modems

DNIS number 301001

Verifying Call Counters for a Customer Profile

command shows the call counters for a given customer profile. These counters include historical data and can be cleared.

Router# show resource-pool customer ACME

3 active connections

41 calls accepted

3 max number of simultaneous connections

11 calls rejected due to profile limits

2 calls rejected due to resource unavailable

0 minutes spent with max connections

5 overflow connections

1 overflow states entered

11 overflow connections rejected

10 minutes spent in overflow

214 minutes since last clear command

Clearing Call Counters

command clears the call counters.

Verifying Call Counters for a Discriminator Profile

command shows the call counters for a given discriminator profile. These counters include historical data and can be cleared.

Router# show resource-pool discriminator

List of Call Discriminator Profiles:

deny_DNIS

Router# show resource-pool discriminator deny_DNIS

1 calls rejected

Verifying Call Counters for a Resource Group

command shows the call counters for a given resource group. These counters include historical data and can be cleared.

Router# show resource-pool resource

List of Resources:

isdn-ports

MICA-modems

Router# show resource-pool resource isdn-ports

46 resources in the resource group

2 resources currently active

8 calls accepted in the resource group

2 calls rejected due to resource unavailable

0 calls rejected due to resource allocation errors

Verifying Call Counters for a DNIS Group

command shows the call counters for a given DNIS group. These counters include historical data and can be cleared.

Router# show dialer dnis group ACME_dnis_numbers

DNIS Number:301001

11 total connections

5 peak connections

0 calltype mismatches

Verifying Call Counters for a VPDN Profile

command shows the call counters for a given VPDN profile or the tunnel information for a given VPDN group. These counters include historical data and can be cleared.

Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.

Router# show resource-pool vpdn profile ACME_VPDN

2 active connections

2 max number of simultaneous connections

0 calls rejected due to profile limits

0 calls rejected due to resource unavailable

0 overflow connections

0 overflow states entered

0 overflow connections rejected

215 minutes since last clear command

Router# show resource-pool vpdn group outgoing-2

VPDN Group outgoing-2 found under VPDN Profiles: ACME_VPDN

Tunnel (L2F)

------

dnis:301001

dnis:ACME_dnis_numbers

Endpoint Session Limit Priority Active Sessions Status Reserved Sessions

-------- ------------- -------- --------------- ------ -----------------

172.16.1.9 * 1 2 OK -

-------- ------------- --------------- -----------------

Total * 2 0

Verifying Load Sharing and Backup

EXEC command shows two different VPDN customer groups:

Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.

Router# show running-config

Building configuration...

.

.

.

vpdn-group customer1-vpdng

request dialin

protocol l2f

domain cisco.com

domain cisco2.com

dnis customer1-calledg

initiate-to ip 172.21.9.67

loadsharing ip 172.21.9.68 limit 100

backup ip 172.21.9.69 priority 5

vpdn-group customer2-vpdng

request dialin

protocol l2tp

dnis customer2-calledg

domain acme.com

initiate-to ip 172.22.9.5

Troubleshooting RPM

commands needed for troubleshooting RPM are as follows:

- debug resource pool

- debug aaa authorization

command for troubleshooting VPDN and modem service problems.

Problems that might typically occur are as follows:

- No DNIS group found or no customer profile uses a default DNIS

- Call discriminator blocks the DNIS

- Customer profile limits exceeded

- Resource group limits exceeded

Note Always enable the debug and log time stamps when troubleshooting RPM.

This section provides the following topics for troubleshooting RPM:

- Resource-Pool Component

- Resource Group Manager

- Signaling Stack

- AAA Component

- VPDN Component

- Troubleshooting DNIS Group Problems

- Troubleshooting Call Discriminator Problems

- Troubleshooting Customer Profile Counts

- Troubleshooting Resource Group Counts

- Troubleshooting VPDN

- Troubleshooting RPMS

Resource-Pool Component

summarizes the resource pooling states.

Table 5 Resource Pooling States

State

Description

RM_IDLE

No call activity.

RM_RES_AUTHOR

Call waiting for authorization; message sent to AAA.

RM_RES_ALLOCATING

Call authorized; resource group manager allocating.

RM_RES_ALLOCATED

Resource allocated; connection acknowledgment sent to signaling state. Call should get connected and become active.

RM_AUTH_REQ_IDLE

Signaling module disconnected call while in RM_RES_AUTHOR. Waiting for authorization response from AAA.

RM_RES_REQ_IDLE

Signaling module disconnected call while in RM_RES_ALLOCATING. Waiting for resource allocation response from resource group manager.

The resource-pool state can be used to isolate problems. For example, if a call fails authorization in the RM_RES_AUTHOR state, investigate further with AAA authorization debugs to determine whether the problem lies in the resource-pool manager, AAA, or dispatcher.

The resource-pool component also contains local customer profiles and discriminators, and is responsible for matching, configuring, and maintaining the associated counters and statistics. The resource-pool component is responsible for the following:

- Configuration of customer profiles or discriminators

- Matching a customer profile or discriminator for local profile configuration

- Counters/statistics for customer profiles or discriminators

- Active call information displayed by the show resource-pool call command

.

Table 6 Debug Commands for RPM

Command

Purpose

This debug output should be sufficient for most RPM troubleshooting situations.

This debug output provides more specific information and shows the actual DNIS numbers passed and call types used.

Successful Resource Pool Connection

command displays a successful RPM connection. The entries in bold are of particular importance.

*Mar 1 02:14:57.439: RM state:RM_IDLE event:DIALER_INCALL DS0:0:0:0:21

*Mar 1 02:14:57.439: RM: event incoming call

*Mar 1 02:14:57.443: RM state:RM_DNIS_AUTHOR event:RM_DNIS_RPM_REQUEST DS0:0:0:0:21

*Mar 1 02:14:57.447: RM:RPM event incoming call

*Mar 1 02:14:57.459: RPM profile ACME found

*Mar 1 02:14:57.487: RM state:RM_RPM_RES_AUTHOR event:RM_RPM_RES_AUTHOR_SUCCESS

DS0:0:0:0:21

*Mar 1 02:14:57.487: Allocated resource from res_group isdn-ports

*Mar 1 02:14:57.491: RM:RPM profile "ACME", allocated resource "isdn-ports" successfully

*Mar 1 02:14:57.495: RM state:RM_RPM_RES_ALLOCATING event:RM_RPM_RES_ALLOC_SUCCESS DS0:0:0:0:21

*Mar 1 02:14:57.603: %LINK-3-UPDOWN: Interface Serial0:21, changed state to up

*Mar 1 02:15:00.879: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0:21, changed state to up

Dialer Component

The dialer component contains DNIS groups and is responsible for configuration, and maintenance of counters and statistics. The resource-pool component is responsible for the following:

- DNIS number statistics or counters

- Configuring DNIS groups

Resource Group Manager

Resource groups are created, maintained, allocated, freed, and tallied by the resource group manager. The resource group manager is also responsible for service profiles, which are applied to resources at call setup time. The resource group manager is responsible for:

- Allocating resources when the profile has been authorized and a valid resource group is received

- Statistics or configuration of resource groups

- Configuring or applying service profiles to resource groups

- Collecting DNIS number information for channel-associated signaling calls

Signaling Stack

The signaling stacks currently supported in resource pooling are CAS and ISDN. The signaling stack delivers the incoming call to the resource-pool dispatcher and provides call-type and DNIS number information to the resource-pool dispatcher. Depending on configuration, call connect attempts may fail if the signaling stacks do not send the DNIS number and the call type to the resource-pool dispatcher. Call attempts will also fail if signaling stacks disconnect prematurely, not giving enough time for authorization or resource allocation processes to complete.

commands are used on the Cisco AS5800 access server.

AAA Component

In context with resource pooling, the AAA component is responsible for the following:

- Authorization of profiles between the resource-pool dispatcher and local or external resource-pool manager

- Accounting messages between the resource-pool dispatcher and external resource-pool manager for resource allocation

- VPDN authorization between VPDN and the local or external resource-pool manager

- VPDN accounting messages between VPDN and the external resource-pool manager

- Overflow accounting records between the AAA server and resource-pool dispatcher

- Resource connect speed accounting records between the AAA server and resource group

VPDN Component

The VPDN component is responsible for the following:

- Creating VPDN groups and profiles

- Searching or matching groups based on domain or DNIS

- Maintaining counts and statistics for the groups and profiles

- Setting up the tunnel between the NAS/LAC and HGW/LNS

The VPDN component interfaces with AAA to get VPDN tunnel authorization on the local or remote resource-pool manager. VPDN and AAA debugging traces should be used for troubleshooting.

Troubleshooting DNIS Group Problems

command displays a customer profile that is not found for a particular DNIS group:

*Mar 1 00:38:21.011: RM state:RM_IDLE event:DIALER_INCALL DS0:0:0:0:3

*Mar 1 00:38:21.011: RM: event incoming call

*Mar 1 00:38:21.015: RM state:RM_DNIS_AUTHOR event:RM_DNIS_RPM_REQUEST DS0:0:0:0:3

*Mar 1 00:38:21.019: RM:RPM event incoming call

*Mar 1 00:38:21.103: RPM no profile found for call-type digital in default DNIS number

*Mar 1 00:38:21.155: RM:RPM profile rejected do not allocate resource

*Mar 1 00:38:21.155: RM state:RM_RPM_RES_AUTHOR event:RM_RPM_RES_AUTHOR_FAIL DS0:0:0:0:3

*Mar 1 00:38:21.163: RM state:RM_RPM_DISCONNECTING event:RM_RPM_DISC_ACK DS0:0:0:0:3

Troubleshooting Call Discriminator Problems

command displays an incoming call that is matched against a call discriminator profile:

*Mar 1 00:35:25.995: RM state:RM_IDLE event:DIALER_INCALL DS0:0:0:0:4

*Mar 1 00:35:25.999: RM: event incoming call

*Mar 1 00:35:25.999: RM state:RM_DNIS_AUTHOR event:RM_DNIS_RPM_REQUEST DS0:0:0:0:4

*Mar 1 00:35:26.003: RM:RPM event incoming call

*Mar 1 00:35:26.135: RM:RPM profile rejected do not allocate resource

*Mar 1 00:35:26.139: RM state:RM_RPM_RES_AUTHOR event:RM_RPM_RES_AUTHOR_FAIL DS0:0:0:0:4

*Mar 1 00:35:26.143: RM state:RM_RPM_DISCONNECTING event:RM_RPM_DISC_ACK DS0:0:0:0:4

Troubleshooting Customer Profile Counts

command displays what happens once the customer profile limits have been reached:

*Mar 1 00:43:33.275: RM state:RM_IDLE event:DIALER_INCALL DS0:0:0:0:9

*Mar 1 00:43:33.279: RM: event incoming call

*Mar 1 00:43:33.279: RM state:RM_DNIS_AUTHOR event:RM_DNIS_RPM_REQUEST DS0:0:0:0:9

*Mar 1 00:43:33.283: RM:RPM event incoming call

*Mar 1 00:43:33.295: RPM count exceeded in profile ACME

*Mar 1 00:43:33.315: RM:RPM profile rejected do not allocate resource

*Mar 1 00:43:33.315: RM state:RM_RPM_RES_AUTHOR event:RM_RPM_RES_AUTHOR_FAIL DS0:0:0:0:9

*Mar 1 00:43:33.323: RM state:RM_RPM_DISCONNECTING event:RM_RPM_DISC_ACK DS0:0:0:0:9

Troubleshooting Resource Group Counts

command displays the resources within a resource group all in use:

*Mar 1 00:52:34.411: RM state:RM_IDLE event:DIALER_INCALL DS0:0:0:0:19

*Mar 1 00:52:34.411: RM: event incoming call

*Mar 1 00:52:34.415: RM state:RM_DNIS_AUTHOR event:RM_DNIS_RPM_REQUEST DS0:0:0:0:19

*Mar 1 00:52:34.419: RM:RPM event incoming call

*Mar 1 00:52:34.431: RPM profile ACME found

*Mar 1 00:52:34.455: RM state:RM_RPM_RES_AUTHOR event:RM_RPM_RES_AUTHOR_SUCCESS DS0:0:0:0:19

*Mar 1 00:52:34.459: All resources in res_group isdn-ports are in use

*Mar 1 00:52:34.463: RM state:RM_RPM_RES_ALLOCATING event:RM_RPM_RES_ALLOC_FAIL DS0:0:0:0:19

*Mar 1 00:52:34.467: RM:RPM failed to allocate resources for "ACME"

Troubleshooting VPDN

Troubleshooting problems that might typically occur are as follows:

- Customer profile is not associated with a VPDN profile or VPDN group (the call will be locally terminated in this case. Regular VPDN can still succeed even if RPM/VPDN fails).

- VPDN profile limits have been reached (call answered but disconnected).

- VPDN group limits have been reached (call answered but disconnected).

- VPDN endpoint is not reachable (call answered but disconnected).

Troubleshooting RPM/VPDN Connection

command displays a successful RPM/VPDN connection. The entries in bold are of particular importance.

Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.

*Mar 1 00:15:53.639: Se0:10 RM/VPDN/rm-session-request: Allocated vpdn info for domain NULL MLP Bundle SOHO

*Mar 1 00:15:53.655: RM/VPDN/ACME_VPDN: VP LIMIT/ACTIVE/RESERVED/OVERFLOW are now 6/0/0/0

*Mar 1 00:15:53.659: RM/VPDN/ACME_VPDN: Session reserved for outgoing-2

*Mar 1 00:15:53.695: Se0:10 RM/VPDN: Session has been authorized using dnis:ACME_dnis_numbers

*Mar 1 00:15:53.695: Se0:10 RM/VPDN/session-reply: NAS name HQ-NAS

*Mar 1 00:15:53.699: Se0:10 RM/VPDN/session-reply: Endpoint addresses 172.16.1.9

*Mar 1 00:15:53.703: Se0:10 RM/VPDN/session-reply: VPDN tunnel protocol l2f

*Mar 1 00:15:53.703: Se0:10 RM/VPDN/session-reply: VPDN Group outgoing-2

*Mar 1 00:15:53.707: Se0:10 RM/VPDN/session-reply: VPDN domain dnis:ACME_dnis_numbers

*Mar 1 00:15:53.767: RM/VPDN: MLP Bundle SOHO Session Connect with 1 Endpoints:

*Mar 1 00:15:53.771: IP 172.16.1.9 OK

*Mar 1 00:15:53.771: RM/VPDN/rm-session-connect/ACME_VPDN: VP LIMIT/ACTIVE/RESERVED/OVERFLOW are now 6/1/0/0

*Mar 1 00:15:54.815: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0:10, changed state to up

*Mar 1 00:15:57.399: %ISDN-6-CONNECT: Interface Serial0:10 is now connected to SOHO

Troubleshooting Customer/VPDN Profile

command, as shown here, does not effectively reflect the problem:

Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.

*Mar 1 03:40:16.483: Se0:15 RM/VPDN/rm-session-request: Allocated vpdn info for domain NULL MLP Bundle SOHO

*Mar 1 03:40:16.515: Se0:15 RM/VPDN/rm-session-request: Authorization failed

*Mar 1 03:40:16.527: %VPDN-6-AUTHORERR: L2F NAS HQ-NAS cannot locate a AAA server for Se0:15 user SOHO

*Mar 1 03:40:16.579: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up

*Mar 1 03:40:17.539: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0:15, changed state to up

*Mar 1 03:40:17.615: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up

*Mar 1 03:40:19.483: %ISDN-6-CONNECT: Interface Serial0:15 is now connected to SOHO

command output appears as follows:

*Mar 1 04:03:49.846: Se0:19 RM/VPDN/rm-session-request: Allocated vpdn info for domain NULL MLP Bundle SOHO

*Mar 1 04:03:49.854: Se0:19 AAA/AUTHOR/RM vpdn-session (3912941997): Port='DS0:0:0:0:19' list='default' service=RM

*Mar 1 04:03:49.858: AAA/AUTHOR/RM vpdn-session: Se0:19 (3912941997) user='301001'

*Mar 1 04:03:49.862: Se0:19 AAA/AUTHOR/RM vpdn-session (3912941997): send AV service=resource-management

*Mar 1 04:03:49.866: Se0:19 AAA/AUTHOR/RM vpdn-session (3912941997): send AV protocol=vpdn-session

*Mar 1 04:03:49.866: Se0:19 AAA/AUTHOR/RM vpdn-session (3912941997): send AV rm-protocol-version=1.0

*Mar 1 04:03:49.870: Se0:19 AAA/AUTHOR/RM vpdn-session (3912941997): send AV rm-nas-state=3278356

*Mar 1 04:03:49.874: Se0:19 AAA/AUTHOR/RM vpdn-session (3912941997): send AV rm-call-handle=27

*Mar 1 04:03:49.878: Se0:19 AAA/AUTHOR/RM vpdn-session (3912941997): send AV multilink-id=SOHO

*Mar 1 04:03:49.878: Se0:19 AAA/AUTHOR/RM vpdn-session (3912941997): found list "default"

*Mar 1 04:03:49.882: Se0:19 AAA/AUTHOR/RM vpdn-session (3912941997): Method=LOCAL

*Mar 1 04:03:49.886: Se0:19 AAA/AUTHOR/RM/local (3912941997): Received AV service=resource-management

*Mar 1 04:03:49.890: Se0:19 AAA/AUTHOR/RM/local (3912941997): Received AV protocol=vpdn-session

*Mar 1 04:03:49.890: Se0:19 AAA/AUTHOR/RM/local (3912941997): Received AV rm-protocol-version=1.0

*Mar 1 04:03:49.894: Se0:19 AAA/AUTHOR/RM/local (3912941997): Received AV rm-nas-state=3278356

*Mar 1 04:03:49.898: Se0:19 AAA/AUTHOR/RM/local (3912941997): Received AV rm-call-handle=27

*Mar 1 04:03:49.902: Se0:19 AAA/AUTHOR/RM/local (3912941997): Received AV multilink-id=SOHO

*Mar 1 04:03:49.906: Se0:19 AAA/AUTHOR/VPDN/RM/LOCAL: Customer ACME has no VPDN group for session dnis:ACME_dnis_numbers

*Mar 1 04:03:49.922: Se0:19 AAA/AUTHOR (3912941997): Post authorization status = FAIL

Troubleshooting VPDN Profile Limits

command displays that VPDN profile limits have been reached:

Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.

*Mar 1 04:57:53.762: Se0:13 RM/VPDN/rm-session-request: Allocated vpdn info for domain NULL MLP Bundle SOHO

*Mar 1 04:57:53.774: RM/VPDN/ACME_VPDN: VP LIMIT/ACTIVE/RESERVED/OVERFLOW are now 0/0/0/0

*Mar 1 04:57:53.778: RM/VPDN/ACME_VPDN: Session outgoing-2 rejected due to Session Limit

*Mar 1 04:57:53.798: Se0:13 RM/VPDN/rm-session-request: Authorization failed

*Mar 1 04:57:53.802: %VPDN-6-AUTHORFAIL: L2F NAS HQ-NAS, AAA authorization failure for Se0:13 user SOHO; At Session Max

*Mar 1 04:57:53.866: %ISDN-6-DISCONNECT: Interface Serial0:13 disconnected from SOHO, call lasted 2 seconds

*Mar 1 04:57:54.014: %LINK-3-UPDOWN: Interface Serial0:13, changed state to down

*Mar 1 04:57:54.050: RM state:RM_RPM_RES_ALLOCATED event:DIALER_DISCON DS0:0:0:0:13

*Mar 1 04:57:54.054: RM:RPM event call drop

*Mar 1 04:57:54.054: Deallocated resource from res_group isdn-ports

Troubleshooting VPDN Group Limits

described in the “Troubleshooting RPMS” section later in this chapter:

Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.

*Mar 1 05:02:22.314: Se0:17 RM/VPDN/rm-session-request: Allocated vpdn info for domain NULL MLP Bundle SOHO

*Mar 1 05:02:22.334: RM/VPDN/ACME_VPDN: VP LIMIT/ACTIVE/RESERVED/OVERFLOW are now 5/0/0/0

*Mar 1 05:02:22.334: RM/VPDN/ACME_VPDN: Session reserved for outgoing-2

*Mar 1 05:02:22.358: Se0:17 RM/VPDN/rm-session-request: Authorization failed

*Mar 1 05:02:22.362: %VPDN-6-AUTHORFAIL: L2F NAS HQ-NAS, AAA authorization failure for Se0:17 user SOHO; At Multilink Bundle Limit

*Mar 1 05:02:22.374: %ISDN-6-DISCONNECT: Interface Serial0:17 disconnected from SOHO, call lasted 2 seconds

*Mar 1 05:02:22.534: %LINK-3-UPDOWN: Interface Serial0:17, changed state to down

*Mar 1 05:02:22.570: RM state:RM_RPM_RES_ALLOCATED event:DIALER_DISCON DS0:0:0:0:17

*Mar 1 05:02:22.574: RM:RPM event call drop

*Mar 1 05:02:22.574: Deallocated resource from res_group isdn-ports

Troubleshooting VPDN Endpoint Problems

command displays that the IP endpoint for the VPDN group is not reachable:

Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.

*Mar 1 05:12:22.330: Se0:21 RM/VPDN/rm-session-request: Allocated vpdn info for domain NULL MLP Bundle SOHO

*Mar 1 05:12:22.346: RM/VPDN/ACME_VPDN: VP LIMIT/ACTIVE/RESERVED/OVERFLOW are now 5/0/0/0

*Mar 1 05:12:22.350: RM/VPDN/ACME_VPDN: Session reserved for outgoing-2

*Mar 1 05:12:22.382: Se0:21 RM/VPDN: Session has been authorized using dnis:ACME_dnis_numbers

*Mar 1 05:12:22.386: Se0:21 RM/VPDN/session-reply: NAS name HQ-NAS

*Mar 1 05:12:22.386: Se0:21 RM/VPDN/session-reply: Endpoint addresses 172.16.1.99

*Mar 1 05:12:22.390: Se0:21 RM/VPDN/session-reply: VPDN tunnel protocol l2f

*Mar 1 05:12:22.390: Se0:21 RM/VPDN/session-reply: VPDN Group outgoing-2

*Mar 1 05:12:22.394: Se0:21 RM/VPDN/session-reply: VPDN domain dnis:ACME_dnis_numbers

*Mar 1 05:12:25.762: %ISDN-6-CONNECT: Interface Serial0:21 is now connected to SOHO

*Mar 1 05:12:27.562: %VPDN-5-UNREACH: L2F HGW 172.16.1.99 is unreachable

*Mar 1 05:12:27.578: RM/VPDN: MLP Bundle SOHO Session Connect with 1 Endpoints:

*Mar 1 05:12:27.582: IP 172.16.1.99 Destination unreachable

Troubleshooting RPMS

command is more useful for troubleshooting with RPMS. Following is sample output:

Router# debug aaa authorization

AAA Authorization debugging is on

Router# show debug

General OS:

AAA Authorization debugging is on

Resource Pool:

resource-pool general debugging is on

commands shows a successful RPM connection:

*Mar 1 06:10:35.450: AAA/MEMORY: create_user (0x723D24) user='301001' ruser=''port='DS0:0:0:0:12' rem_addr='102' authen_type=NONE service=NONE priv=0

*Mar 1 06:10:35.462: DS0:0:0:0:12 AAA/AUTHOR/RM call-accept (2784758907): Port='DS0:0:0:0:12' list='default' service=RM

*Mar 1 06:10:35.466: AAA/AUTHOR/RM call-accept: DS0:0:0:0:12 (2784758907) user= '301001'

*Mar 1 06:10:35.470: DS0:0:0:0:12 AAA/AUTHOR/RM call-accept (2784758907): send AV service=resource-management

*Mar 1 06:10:35.470: DS0:0:0:0:12 AAA/AUTHOR/RM call-accept (2784758907): send AV protocol=call-accept

*Mar 1 06:10:35.474: DS0:0:0:0:12 AAA/AUTHOR/RM call-accept (2784758907): send AV rm-protocol-version=1.0

*Mar 1 06:10:35.478: DS0:0:0:0:12 AAA/AUTHOR/RM call-accept (2784758907): send AV rm-nas-state=7513368

*Mar 1 06:10:35.482: DS0:0:0:0:12 AAA/AUTHOR/RM call-accept (2784758907): send AV rm-call-type=speech

*Mar 1 06:10:35.486: DS0:0:0:0:12 AAA/AUTHOR/RM call-accept (2784758907): send AV rm-request-type=dial-in

*Mar 1 06:10:35.486: DS0:0:0:0:12 AAA/AUTHOR/RM call-accept (2784758907): send AV rm-link-type=isdn

*Mar 1 06:10:35.490: DS0:0:0:0:12 AAA/AUTHOR/RM call-accept (2784758907): found list "default"

*Mar 1 06:10:35.494: DS0:0:0:0:12 AAA/AUTHOR/RM call-accept (2784758907): Method=LOCAL

*Mar 1 06:10:35.498: DS0:0:0:0:12 AAA/AUTHOR/RM/local (2784758907):Received DNIS=301001

*Mar 1 06:10:35.498: DS0:0:0:0:12 AAA/AUTHOR/RM/local (2784758907):Received CLID=102

*Mar 1 06:10:35.502: DS0:0:0:0:12 AAA/AUTHOR/RM/local (2784758907):Received Port=DS0:0:0:0:12

*Mar 1 06:10:35.506: DS0:0:0:0:12 AAA/AUTHOR/RM/local (2784758907): Received AV service=resource-management

*Mar 1 06:10:35.510: DS0:0:0:0:12 AAA/AUTHOR/RM/local (2784758907): Received AV protocol=call-accept

*Mar 1 06:10:35.510: DS0:0:0:0:12 AAA/AUTHOR/RM/local (2784758907): Received AV rm-protocol-version=1.0

*Mar 1 06:10:35.514: DS0:0:0:0:12 AAA/AUTHOR/RM/local (2784758907): Received AV rm-nas-state=7513368

*Mar 1 06:10:35.518: DS0:0:0:0:12 AAA/AUTHOR/RM/local (2784758907): Received AV rm-call-type=speech

*Mar 1 06:10:35.522: DS0:0:0:0:12 AAA/AUTHOR/RM/local (2784758907): Received AV rm-request-type=dial-in

*Mar 1 06:10:35.526: DS0:0:0:0:12 AAA/AUTHOR/RM/local (2784758907): Received AV rm-link-type=isdn

*Mar 1 06:10:35.542: AAA/AUTHOR (2784758907): Post authorization status = PASS_REPL

*Mar 1 06:10:35.546: DS0:0:0:0:12 AAA/AUTHOR/RM/call-accept (2784758907): Processing AV service=resource-management

*Mar 1 06:10:35.550: DS0:0:0:0:12 AAA/AUTHOR/RM/call-accept (2784758907): Processing AV protocol=call-accept

*Mar 1 06:10:35.554: DS0:0:0:0:12 AAA/AUTHOR/RM/call-accept (2784758907): Processing AV rm-protocol-version=1.0

*Mar 1 06:10:35.558: DS0:0:0:0:12 AAA/AUTHOR/RM/call-accept (2784758907): Processing AV rm-response-code=overflow

*Mar 1 06:10:35.558: DS0:0:0:0:12 AAA/AUTHOR/RM/call-accept (2784758907): Processing AV rm-call-handle=47

*Mar 1 06:10:35.562: DS0:0:0:0:12 AAA/AUTHOR/RM/call-accept (2784758907): Processing AV rm-call-count=2

*Mar 1 06:10:35.566: DS0:0:0:0:12 AAA/AUTHOR/RM/call-accept (2784758907): Processing AV rm-cp-name=ACME

*Mar 1 06:10:35.570: DS0:0:0:0:12 AAA/AUTHOR/RM/call-accept (2784758907): Processing AV rm-rg-name#0=MICA-modems

*Mar 1 06:10:35.574: DS0:0:0:0:12 AAA/AUTHOR/RM/call-accept (2784758907): Processing AV rm-rg-service-name#0=gold

*Mar 1 06:10:35.578: DS0:0:0:0:12 AAA/AUTHOR/RM/call-accept (2784758907): Processing AV rm-call-treatment=busy

*Mar 1 06:10:35.582: DS0:0:0:0:12 AAA/AUTHOR/RM/call-accept (2784758907): Processing AV rm-call-type=speech

Configuration Examples for RPM

The following sections provide RPM configuration examples:

- Standard Configuration for RPM Example

- Customer Profile Configuration for DoVBS Example

- DNIS Discriminator Profile Example

- CLID Discriminator Profile Example

- Direct Remote Services Configuration Example

- VPDN Configuration Example

- VPDN Load Sharing and Backing Up Between Multiple HGW/LNSs Example

Standard Configuration for RPM Example

The following example demonstrates a basic RPM configuration:

resource-pool enable

resource-pool call treatment resource busy

resource-pool call treatment profile no-answer

!

resource-pool group resource isdn-ports

range limit 46

resource-pool group resource MICA-modems

range port 1/0 2/23

!

resource-pool profile customer ACME

limit base-size 30

limit overflow-size 10

resource isdn-ports digital

resource MICA-modems speech service gold

dnis group ACME_dnis_numbers

!

resource-pool profile customer DEFAULT

limit base-size 10

resource MICA-modems speech service silver

dnis group default

resource-pool profile discriminator deny_DNIS

call-type digital

dnis group bye-bye

!

resource-pool profile service gold

modem min-speed 33200 max-speed 56000 modulation v90

resource-pool profile service silver

modem min-speed 19200 max-speed 33200 modulation v34

!

resource-pool aaa protocol local

!

dialer dnis group ACME_dnis_numbers

number 301001

dialer dnis group bye-bye

number 301005

Tip • Replace the command string resource isdn-ports digital in the previous example with resource isdn-ports speech to set up DoVBS. See the section, “Customer Profile Configuration for DoVBS Example,” for more information.

Tip • Replace the command string resource isdn-ports digital in the previous example with resource isdn-ports speech to set up DoVBS. See the section, “Customer Profile Configuration for DoVBS Example,” for more information.

Digital calls to 301001 are associated with the customer ACME by using the resource group “isdn-ports.”

- Speech calls to 301001 are associated with the customer ACME by using the resource group “mica-modems” and allow for V.90 connections (anything less than V.90 is also allowed).

- Digital calls to 301005 are denied.

- All other speech calls to any other DNIS number are associated with the customer profile “DEFAULT” by using the resource group “mica-modems” and allow for V.34 connections (anything more than V.34 is not allowed; anything less than V.34 is also allowed).

- All other digital calls to any other DNIS number are not associated with a customer profile and are therefore not allowed.

- The customer profile named “DEFAULT” serves as the default customer profile for speech calls only. If the solution uses an external RPMS server, this same configuration can be used for backup resource pooling if communication is lost between the NAS and the RPMS.

Customer Profile Configuration for DoVBS Example

To allow ISDN calls with a speech bearer capability to be directed to digital resources, make the following change (highlighted in bold) to the configuration shown in the previous section, “Standard Configuration for RPM Example”:

resource-pool profile customer ACME

limit base-size 30

limit overflow-size 10

resource isdn-ports speech

dnis group ACME_dnis_numbers

This change causes ISDN speech calls (in addition to ISDN digital calls) to be directed to the resource “isdn-ports”; thus, ISDN speech calls provide DoVBS.

DNIS Discriminator Profile Example

The following is sample configuration for a DNIS discriminator. It shows how to enable resource pool management, configure a customer profile, create DNIS groups, and add numbers to the DNIS groups.

aaa new-model

!

! Enable resource pool management

resource-pool enable

!

resource-pool group resource digital

range limit 20

!

! Configure customer profile

resource-pool profile customer cp1

limit base-size all

limit overflow-size 0

resource digital digital

dnis group ok

!

!

isdn switch-type primary-5ess

!

controller T1 0

framing esf

clock source line primary

linecode b8zs

pri-group timeslots 1-24

!

interface Loopback1

ip address 192.168.0.0 255.255.255.0

!

interface Serial0:23

ip unnumbered Loopback1

encapsulation ppp

ip mroute-cache

dialer-group 1

isdn switch-type primary-5ess

no peer default ip address

ppp authentication chap

!

! Configure DNIS groups

dialer dnis group blot

number 5552003

number 3456789

number 2345678

number 1234567

!

dialer dnis group ok

number 89898989

number 5551003

!

dialer-list 1 protocol ip permit

CLID Discriminator Profile Example

The following is a sample configuration of a CLID discriminator. It shows how to enable resource pool management, configure resource groups, configure customer profiles, configure CLID groups and DNIS groups, and add them to discriminator profiles.

version xx.x

no service pad

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname cisco-machine

!

aaa new-model

aaa authentication login djm local

!

username eagle password ***

username infiniti password ***

spe 1/0 1/7

firmware location system:/ucode/mica_port_firmware

spe 2/0 2/7

firmware location system:/ucode/mica_port_firmware

!

! Enable resource pool management

resource-pool enable

!

! Configure resource groups

resource-pool group resource digital

range limit 20

!

! Configure customer profiles

resource-pool profile customer cp1

limit base-size all

limit overflow-size 0

resource digital digital

dnis group ok

!

! Configure discriminator profiles

resource-pool profile discriminator baadaabing

call-type digital

clid group stompIt

!

resource-pool profile discriminator baadaaboom

call-type digital

clid group splat

!

ip subnet-zero

!

isdn switch-type primary-5ess

chat-script dial ABORT BUSY "" AT OK "ATDT \T" TIMEOUT 30 CONNECT \c

!

!

mta receive maximum-recipients 0

partition flash 2 8 8

!

!

controller T1 0

framing esf

clock source line primary

linecode b8zs

pri-group timeslots 1-24

!

controller T1 1

shutdown

clock source line secondary 1

!

controller T1 2

shutdown

clock source line secondary 2

!

controller T1 3

shutdown

clock source line secondary 3

!

controller T1 4

shutdown

clock source line secondary 4

!

controller T1 5

shutdown

clock source line secondary 5

!

controller T1 6

shutdown

clock source line secondary 6

!

controller T1 7

shutdown

clock source line secondary 7

!

interface Loopback0

ip address 192.168.12.1 255.255.255.0

!

interface Loopback1

ip address 192.168.15.1 255.255.255.0

!

interface Loopback2

ip address 192.168.17.1 255.255.255.0

!

interface Ethernet0

ip address 10.0.39.15 255.255.255.0

no ip route-cache

no ip mroute-cache

!

interface Serial0

no ip address

no ip route-cache

no ip mroute-cache

shutdown

no fair-queue

clockrate 2015232

!

interface Serial1

no ip address

no ip route-cache

no ip mroute-cache

shutdown

no fair-queue

clockrate 2015232

!

interface Serial2

no ip address

no ip route-cache

no ip mroute-cache

shutdown

no fair-queue

clockrate 2015232

!

interface Serial3

no ip address

no ip route-cache

no ip mroute-cache

shutdown

no fair-queue

clockrate 2015232

!

interface Serial0:23

ip unnumbered Loopback1

encapsulation ppp

ip mroute-cache

dialer-group 1

isdn switch-type primary-5ess

no peer default ip address

ppp authentication chap pap

!

interface FastEthernet0

ip address 10.0.38.15 255.255.255.0

no ip route-cache

no ip mroute-cache

duplex half

speed 100

!

!

ip local pool default 192.168.13.181 192.168.13.226

ip classless

ip route 172.25.0.0 255.0.0.0 Ethernet0

ip route 172.19.0.0 255.0.0.0 Ethernet0

no ip http server

!

!

! Configure DNIS groups

dialer dnis group blot

number 4085551003

number 5552003

number 2223333

number 3456789

number 2345678

number 1234567

!

dialer dnis group ok

number 89898989

number 4084442002

number 4085552002

number 5551003

!

dialer clid group splat

number 12321224

!

! Configure CLID groups

dialer clid group zot

number 2121212121

number 4085552002

!

dialer clid group snip

number 1212121212

!

dialer clid group stompIt

number 4089871234

!

dialer clid group squash

number 5656456

dialer-list 1 protocol ip permit

!

!

!

line con 0

exec-timeout 0 0

logging synchronous

transport input none

line 1 96

no exec

exec-timeout 0 0

autoselect ppp

line aux 0

line vty 0 4

exec-timeout 0 0

transport input none

!

scheduler interval 1000

end

Direct Remote Services Configuration Example

The following example shows a direct remote services configuration:

resource-pool profile customer ACME

limit base-size 30

limit overflow-size 10

resource isdn-ports digital

resource MICA-modems speech service gold

dnis group ACME_dnis_numbers

aaa group-configuration tahoe

source template acme_direct

!

resource-pool profile customer DEFAULT

limit base-size 10

resource MICA-modems speech service silver

dnis group default

resource-pool profile discriminator deny_DNIS

call-type digital

dnis group bye-bye

!

resource-pool profile service gold

modem min-speed 33200 max-speed 56000 modulation v90

resource-pool profile service silver

modem min-speed 19200 max-speed 33200 modulation v34

!

resource-pool aaa protocol local

!

template acme_direct

peer default ip address pool tahoe

ppp authentication chap isdn-users

ppp multilink

!

dialer dnis group ACME_dnis_numbers

number 301001

dialer dnis group bye-bye

number 301005

VPDN Configuration Example

Adding the following commands to those listed in the section “Standard Configuration for RPM Example” earlier in this chapter allows you to use VPDN by setting up a VPDN profile and a VPDN group:

Note If the limits imposed by the VPDN profile are not required, do not configure the VPDN profile. Replace the vpdn profile ACME_VPDN command under the customer profile ACME with the vpdn group outgoing-2 command.

resource-pool profile vpdn ACME_VPDN

limit base-size 6

limit overflow-size 0

vpdn group outgoing-2

!

resource-pool profile customer ACME

limit base-size 30

limit overflow-size 10

resource isdn-ports digital

resource MICA-modems speech service gold

dnis group ACME_dnis_numbers

!

vpdn profile ACME_VPDN

!

vpdn enable

!

vpdn-group outgoing-2

request dialin

protocol 12f

dnis ACME_dnis_numbers

local name HQ-NAS

initiate-to ip 172.16.1.9

multilink bundle 1

multilink link 2

!

dialer dnis group ACME_dnis_numbers

number 301001

VPDN Load Sharing and Backing Up Between Multiple HGW/LNSs Example

Cisco IOS software enables you to balance and back up VPDN sessions across multiple tunnel endpoints (HGW/LNS). When a user or session comes into the NAS/LAC, a VPDN load-balancing algorithm is triggered and applied to the call. The call is then passed to an available HGW/LNS. You can modify this function by limiting the number of sessions supported on an HGW/LNS router and limiting the number of MLP bundles and links.

Figure 11 shows an example of one NAS/LAC that directs calls to two HGW/LNS routers by using the L2TP tunneling protocol. Each router has a different number of supported sessions and works at a different speed. The NAS/LAC is counting the number of active simultaneous sessions sent to each HGW/LNS.

Figure 11 Home Gateway Load Sharing and Backup

In a standalone NAS environment (no RPMS server used), the NAS has complete knowledge of the status of tunnel endpoints. Balancing across endpoints is done by a “least-filled tunnel” or a “next-available round robin” approach. In an RPMS-controlled environment, RPMS has the complete knowledge of tunnel endpoints. However, the NAS still has the control over those tunnel endpoints selected by RPMS.

A standalone NAS uses the following default search criteria for load-balancing traffic across multiple endpoints (HGW/LNS):

- Select any idle endpoint—an HGW/LNS with no active sessions.

- Select an active endpoint that currently has a tunnel established with the NAS.

- If all specified load-sharing routers are busy, select the backup HGW. If all endpoints are busy, report that the NAS cannot find an IP address to establish the call.

Note This default search order criteria is independent of the Cisco RPMS application scenario. A standalone NAS uses a different load-sharing algorithm than the Cisco RPMS. This search criteria will change as future enhancements become available.

The following is an example of VPDN load sharing between multiple HGW/LNSs:

vpdn enable

!

vpdn-group outgoing-2

request dialin

protocol l2tp

dnis ACME_dnis_numbers

local name HQ-NAS

initiate-to ip 172.16.1.9

loadsharing ip 172.16.1.9 limit 200

loadsharing ip 172.16.2.17 limit 50

backup ip 172.16.3.22

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007–2009 Cisco Systems, Inc. All rights reserved.

Configuring Wholesale Dial Performance Optimization

This chapter describes the Wholesale Dial Performance Optimization feature in the following sections:

- Wholesale Dial Performance Optimization Feature Overview

- How to Configure Automatic Command Execution

- How to Configure TCP Clear Performance Optimization

- Verifying Configuration of Preauthentication with ISDN PRI and Channel-Associated Signalling

Note This task provides inbound and outbound performance optimization for wholesale dial customers who provide ports to America Online (AOL). It is configured only on Cisco AS5800 access servers.

Wholesale Dial Performance Optimization Feature Overview

command.

- Outbound—Provides stream processing, allowing the output data processing to occur at the interrupt level. Being event driven, this removes polling and process switching overhead. In addition, the flow control algorithm is enhanced to handle the higher volume of traffic and to eliminate some out-of-resource conditions that could result in abnormal termination of the session.

- Inbound—Provides stream processing with the same improvements as for outbound traffic. Also, it removes scanning for special escape characters in the data stream; this is very process-intensive and is not required for this application. (In other situations, the escape characters allow for a return to the privileged EXEC mode prompt (#) on the router.) In addition, Nagle’s algorithm is used to form the inbound data stream into larger packets, thus minimizing packet-processing overhead.

This configuration is designed to provide more efficiency in the data transfers for AOL port suppliers who are using a Cisco network access server to communicate with a wholesale dial carrier.

The Cisco AS5800 access server is required to support all dial-in lines supported by two complete T3 connections (that is, 1344 connections) running TCP Clear connections to an internal host. The desired average data throughput for these connections is 6 kbps outbound and 3 kbps inbound.

facility.

How to Configure Automatic Command Execution

The following are three options for configuring the autocommand telnet /stream line configuration command:

- Automatic command execution can be configured on the lines.

- Automatic command execution can be configured using user ID and password.

- Automatic command execution can also be configured at a TACACS/RADIUS server, if the username authentication is to be performed there, rather than on the router.

To configure automatic command execution on the lines of a Cisco AS5800 universal network access server, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Selects the lines to be configured and begins line configuration mode.

Step 2

Configures autocommand on the lines.

To configure automatic command execution using a user ID and password on a Cisco AS5800 universal network access server, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Defines the user ID and password.

Step 2

Configures autocommand on the user ID.

You can also configure automatic command execution at a TACACS/RADIUS server if the username authentication is to be performed there rather than on the router. The AV-pair processing allows autocommand to be configured.

How to Configure TCP Clear Performance Optimization

To enable TCP Clear performance optimization, automatic command execution must be configured to enable Telnet faststream capability. To implement TCP Clear performance optimization on a Cisco AS5800 universal network access server, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Selects the lines to be configured and begins line configuration mode.

Step 2

Enables the TCP Clear performance optimization on the selected lines.

Verifying Configuration of Preauthentication with ISDN PRI and Channel-Associated Signalling

command. In the following example, Telnet faststream is enabled under “Capabilities”.

Router# show line 1/4/00

Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int

* 1/4/00 Digital modem - inout - - - 1 0 0/0 -

Line 1/4/00, Location: "", Type: ""

Length: 24 lines, Width: 80 columns

Status: PSI Enabled, Ready, Connected, Active, No Exit Banner

Modem Detected

Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out

Modem Callout, Modem RI is CD, Line usable as async interface

Hangup on Last Close, Modem Autoconfigure, Telnet Faststream

Modem state: Ready

Modem hardware state: CTS DSR DTR RTS

modem=1/4/00, vdev_state(0x00000000)=CSM_OC_STATE, bchan_num=(T1 1/2/0:7:20)

vdev_status(0x00000001): VDEV_STATUS_ACTIVE_CALL.

Group codes: 0, Modem Configured

Special Chars: Escape Hold Stop Start Disconnect Activation

^^x none - - none

Timeouts: Idle EXEC Idle Session Modem Answer Session Dispatch

never never none not set

Idle Session Disconnect Warning

never

Login-sequence User Response

00:00:30

Autoselect Initial Wait

not set

Modem type is 9600.

Session limit is not set.

Time since activation: never

Editing is enabled.

History is enabled, history size is 10.

DNS resolution in show commands is enabled

Full user help is disabled

Allowed transports are telnet. Preferred is lat.

Automatically execute command "telnet 10.100.254.254 2145 /stream"

No output characters are padded

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 200–2009 Cisco Systems, Inc. All rights reserved.

L2TP Large-Scale Dial-Out

Feature History

Release

Modification

12.2(4)T

This feature was introduced.

12.2(11)T

This feature was implemented on Cisco access server platforms.

This document describes the L2TP Large-Scale Dial-Out feature. It includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Configuration Tasks

- Monitoring and Maintaining L2TP Large-Scale Dial-Out

- Configuration Examples

- Command Reference

Feature Overview

The Asynchronous Line Monitoring feature feature enables the Device to dial multiple Layer 2 Tunnel Protocol (L2TP) access concentrators (LACs) from a single L2TP network server (LNS). The LACs are signaled through the LNS and use L2TP to establish the dial sessions. User-defined profiles can be configured on an authentication, authorization, and accounting (AAA) server and retrieved by the LNS when dial-out occurs.The Asynchronous Line Monitoring feature feature also supports multiple LACs bound into one stack group, call traffic load balancing, and outbound call congestion management.

Figure 1 provides an example of L2TP large-scale dial-out session startup. Each part of the process is numbered and described in text following the figure.

Figure 1 Sample Scenario L2TP Large-Scale Dial-Out Session

1. The IP packets arrive at the LNS and are forwarded to the dialer interface by the routing protocol. (A virtual access interface has not been created yet.)

2. A dialer session is created and placed in a pending state while the dialer interface sends a Dial Out Request message to the AAA server requesting the user profile. The AAA server sends the user profile, and the LNS builds a dynamic map based on the reply.

3. The dialer interface looks for its dial resources and finds the virtual private dialup network (VPDN) group. The dialer interface then issues a dial call request to the VPDN group, which creates a virtual access interface. The virtual access interface becomes a member of a rotary group.

4. If there is no existing L2TP tunnel between the LNS and the primary LAC, the LNS would establish one; otherwise, it uses the existing tunnel. The LNS sends an Outgoing Call ReQuest (OCRQ) message, inside of which is the dynamic dialer map, to the primary LAC.

5. Upon receiving the OCRQ message, the primary LAC determines whether it is congested. If the primary LAC is congested, it sends a Stack Group Bidding Protocol (SGBP) Discover message through a new tunnel to the secondary LAC in the scenario depicted in Figure 1, but it could send the message to any other LAC configured in the SGBP stack group.

After the secondary LAC receives the SGBP Discover message from the LNS, it responds with an SGBP Offer message describing available resources.

6. If neither LAC has resources to dial out, the primary LAC would send a Call Disconnect Notification (CDN) message to the LNS. The LNS would then tear down the tunnel.

If the secondary LAC has more resources, the primary LAC can choose to dial through the secondary LAC. The primary LAC sends a CDN message to the LNS with error code 7, which means “Try another” as defined in RFC 2661. Inside this message, the LNS learns that its dial-out request should be redirected to the secondary LAC, and the LNS clears the session to the primary LAC.

7. The LNS creates a new tunnel to the secondary LAC if one does not exist. The dial-out LAC creates a VPDN session and sets it in a pending state. It then places a call to the PPP client. Once the call is connected, the LAC determines to which pending VPDN session the connected interface belongs and binds the connected interface with the session. The secondary LAC sends an Outgoing Call Connected (OCCN) message to the LNS. The LNS determines for which pending virtual access interface and VPDN session this OCCN is meant, and then the LNS brings up the virtual access interface.

Benefits

Large-Scale Dial-Out Integrated with L2TP

Before Cisco IOS Release 12.2(4)T, L2TP required that requests for tunneled dial-out calls be from a single LNS to a single LAC, and that configurations be available on the local server. The Asynchronous Line Monitoring feature feature introduced in Cisco IOS Release 12.2(4)T allows dialing multiple LACs from a single LNS. The LACs are signaled through the LNS using L2TP to establish the dial sessions. User-defined profiles can also be configured on a AAA server and retrieved by the LNS when dial-out occurs.

Enhanced Dial Management

The Asynchronous Line Monitoring feature feature also provides the following benefits:

- Multiple LACs bound into one stack group

- Call traffic load balancing

- Outbound call congestion management

Related Features and Technologies

, Release 12.2. Refer to the chapter “Configuring Virtual Private Networks” in the part “Virtual Templates, Profiles, and Networks,” and the chapter “Configuring Large-Scale Dial-Out” in the part “Dial Access Specialized Features.”

Supported Platforms

See the next section for information about Feature Navigator and how to use this tool to determine the platforms and software images in which this feature is available.

Platform Support Through Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Feature Navigator. Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image.

To access Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions at http://www.cisco.com/register.

Feature Navigator is updated when major Cisco IOS software releases and technology releases occur. As of May 2001, Feature Navigator supports M, T, E, S, and ST releases. You can access Feature Navigator at the following URL:

http://www.cisco.com/go/fn

Supported Standards, MIBs, and RFCs

Standards

None

MIBs

None

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

RFCs

- RFC 2661, Layer Two Tunneling Protocol (L2TP )

Configuration Tasks

See the following sections for configuration tasks for the Asynchronous Line Monitoring feature feature. Each task in the list is identified as either required or optional:

- Configuring the LNS to Request Dial-Out (required)

- Configuring a LAC to Accept Dial-Out (required)

Configuring the LNS to Request Dial-Out

Virtual profiles depend on PPP authentication; therefore the LNS must authenticate the connection to use virtual profiles.

, Release 12.2, describes the commands to configure AAA.

You also need to configure your LNS to communicate with the applicable security server, either a TACACS+ or RADIUS daemon.

, Release 12.2.

, Release 12.2.

To configure the LNS to request dial-out tunneled PPP connections from a LAC, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Enables VPDN and directs the Device to look for tunnel definitions on a remote authorization server.

Step 2

Creates VPDN group 1 and enters VPDN group configuration mode.

Step 3

Enters VPDN request-dialout group configuration mode and enables the tunnel server to send L2TP dial-out requests.

Step 4

Specifies L2TP as the tunneling protocol.

Note L2TP is the only protocol that supports dial-out.

Step 5

Specifies the dialer rotary group that will be used to dial out.

Note You can configure only one dialer rotary group. Attempting to configure a second dialer resource will remove the first from the configuration.

Step 6

Specifies the number of the virtual template that will be used to clone the virtual access interface.

Step 7

Returns to VPDN group configuration mode.

Step 8

Specifies the IP address that will be dialed out. This is the IP address of the LAC.
keywords are not available for VPDN dial-out.

Step 9

Specifies that the L2TP tunnel will identify itself with this host name.

Step 10

Returns to global configuration mode.

Step 11

Specifies the number of the virtual template that will be used to clone the virtual access interface. Enters interface configuration mode so that you can set the configuration parameters that you want applied to virtual access interfaces.

Step 12

Creates a virtual template interface that can be configured and applied dynamically in creating virtual access interfaces.

Step 13

Device(config-if)# no ip directed-broadcast

Disables the translation of a directed broadcast to physical broadcasts.

Step 14

Sets the PPP encapsulation method on the interface.

Step 15

Device(config-if)# ppp multilink

Enables Multilink PPP (MLP) on an interface.

Step 16

Returns to global configuration mode.

Step 17

Device(config)# aaa new-model

Enables AAA access control .

Step 18

Specifies one or more AAA authentication methods for use on serial interfaces that are running PPP. Refer to the Cisco IOS security guides for specific authentication arguments for your network security configuration.

Step 19

Sets parameters that restrict user access to a network. Refer to the Cisco IOS security guides for specific authentication arguments for your network security configuration.

Step 20

Enters interface configuration mode for dialer interface 1.

Step 21

Device(config-if)# dialer in-band

Specifies that DDR is to be supported.

Step 22

Device(config-if)# dialer vpdn

Enables a dialer profile to use L2TP dial-out.

Step 23

Allows a dialer to access the AAA server for dialing information or, optionally, specifies a suffix and nondefault password for authentication.

Step 24

Device(config-if)# no ip directed-broadcast

Disables the translation of a directed broadcast to physical broadcasts.

Step 25

Controls access by configuring an interface to belong to a specific dialing group.

Step 26

}

Defines a DDR dialer list to control dialing by protocol or by a combination of a protocol and a previously defined access list.

Step 27

Sets the PPP encapsulation method on the dialer interface.

Step 28

Device(config-if)# ppp multilink

Enables MLP on an interface.

, Release 12.2, for more information.

See the configuration examples later in this document for additional commands that may be configured on the LAC.

Configuring a LAC to Accept Dial-Out

, Release 12.2, describes the commands to configure a stack group.

Additionally, the information about configuring network security in the section “Configuring the LNS to Request Dial-Out” of this document also applies to configuring the LAC.

To configure a LAC to accept tunneled dial-out connections from the LNS, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Enables VPDN and directs the Device to look for tunnel definitions on a remote authorization server.

Step 2

Creates VPDN group 1 and enters VPDN group configuration mode.

Step 3

Enters VPDN accept-dialout group configuration mode and enables the NAS to accept L2TP dial-out requests.

Step 4

Specifies L2TP as the tunneling protocol.

Note L2TP is the only protocol that supports dial-out.

Step 5

Specifies the dialer that is used to dial out to the client.

Step 6

Returns to VPDN group configuration mode.

Step 7

]

Specifies the IP address that will be tunneled to.

Step 8

Specifies that the L2TP tunnel will identify itself with this host name.

Step 9

Returns to global configuration mode.

Step 10

Device(config)# aaa new-model

Enables the AAA access control model.

Step 11

Specifies one or more AAA authentication methods for use on serial interfaces that are running PPP. Refer to the Cisco IOS security guides for specific authentication arguments for your network security configuration.

Step 12

Sets parameters that restrict user access to a network. Refer to the Cisco IOS security guides for specific authorization arguments for your network security configuration.

Step 13

Creates authentication credentials for the stack group.

Step 14

Creates the stack group and assigns this Device to it.

Step 15

]

Specifies a peer member of the stack group.

Step 16

Enters interface configuration mode for dialer interface 1.

Step 17

Device(config-if)# dialer aaa

Allows a dialer to access the AAA server for dialing information.

Step 18

Device(config-if)# dialer in-band

Specifies that DDR is to be supported.

Step 19

Device(config-if)# no ip directed-broadcast

Disables the translation of a directed broadcast to physical broadcasts.

Step 20

Sets the PPP encapsulation method on the dialer interface.

Step 21

Device(config-if)# ppp multilink

Enables MLP on an interface.

See the configuration examples later in this document for additional commands that may be configured on the LAC.

Verifying L2TP Large-Scale Dial-Out

To verify that L2TP large-scale dial-out is configured correctly, perform the following steps:

EXEC commands:

Device# show vpdn

L2TP Tunnel and Session Information Total tunnels 1 sessions 1

LocID RemID Remote Name State Remote Address Port Sessions

55788 55043 rdt5300-15 est 10.23.1.1 1701 1

LocID RemID TunID Intf Username State Last Chg

Fastswitch

83 50 55788 Vi1 rdt7204-1 est 00:01:08

enabled

%No active L2F tunnels

%No active PPTP tunnels

%No active PPPoE tunnels

Device# show vpdn tunnel all

L2TP Tunnel Information Total tunnels 1 sessions 1

Tunnel id 8873 is up, remote id is 41736, 1 active sessions

Tunnel state is established, time since change 00:00:05

Remote tunnel name is rdt5300-15

Internet Address 10.23.1.1, port 1701

Local tunnel name is rdt7206vxr-8

Internet Address 10.23.1.100, port 1701

11 packets sent, 12 received

653 bytes sent, 666 received

Control Ns 3, Nr 3

Local RWS 10000 (default), Remote RWS 800

Tunnel PMTU checking disabled

Retransmission time 1, max 1 seconds

Unsent queuesize 0, max 0

Resend queuesize 0, max 2

Total resends 0, ZLB ACKs sent 2

Current nosession queue check 0 of 5

Retransmit time distribution: 0 2 0 0 0 0 0 0 0

Sessions disconnected due to lack of resources 0

%No active L2F tunnels

%No active PPTP tunnels

%No active PPPoE tunnels

EXEC command to verify that the interface is up and that no errors are reported:

Device# show interfaces virtual-access 1

Virtual-Access1 is up, line protocol is up

Hardware is Virtual Access interface

MTU 1500 bytes, BW 64 Kbit, DLY 100000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation PPP, loopback not set

DTR is pulsed for 5 seconds on reset

Time to interface disconnect: idle 00:01:16

Interface is bound to Di1 (Encapsulation PPP)

LCP Open, multilink Open

Open: IPCP, CDPCP

Last input 00:00:07, output never, output hang never

Last clearing of "show interface" counters 00:01:33

Input queue: 0/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/1/16 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

Available Bandwidth 48 kilobits/sec

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

9 packets input, 767 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

10 packets output, 849 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

EXEC command:

Device# show ppp multilink

Virtual-Access3, bundle name is rdt7204-1

Bundle up for 00:01:19

Using relaxed lost fragment detection algorithm.

Dialer interface is Dialer1

0 lost fragments, 0 reordered, 0 unassigned

0 discarded, 0 lost received, 1/255 load

0x8 received sequence, 0x8 sent sequence

Member links: 4 (max not set, min not set)

rdt5300-15:Virtual-Access1 (10.23.1.1), since 00:01:19, last rcvd seq

000006, unsequenced

rdt5300-15:Virtual-Access5 (10.23.1.1), since 00:01:18, last rcvd seq

000007, unsequenced

rdt5300-15:Virtual-Access4 (10.23.1.1), since 00:00:48, no frags rcvd,

unsequenced

rdt5300-15:Virtual-Access6 (10.23.1.1), since 00:00:18, no frags rcvd,

unsequenced

EXEC commands:

Device# show vpdn

L2TP Tunnel and Session Information Total tunnels 1 sessions 1

LocID RemID Remote Name State Remote Address Port Sessions

51111 46115 rdt7206vxr-8 est 10.23.1.100 1701 1

LocID RemID TunID Intf Username State Last Chg

Fastswitch

2 86 51111 Se0:22 rdt7204-1 est 00:00:05

enabled

%No active L2F tunnels

%No active PPTP tunnels

%No active PPPoE tunnels

Device# show vpdn tunnel all

L2TP Tunnel Information Total tunnels 1 sessions 1

Tunnel id 51111 is up, remote id is 46115, 1 active sessions

Tunnel state is established, time since change 00:00:18

Remote tunnel name is rdt7206vxr-8

Internet Address 10.23.1.100, port 1701

Local tunnel name is rdt5300-15

Internet Address 10.23.1.1, port 1701

13 packets sent, 12 received

1156 bytes sent, 677 received

Control Ns 3, Nr 3

Local RWS 800 (default), Remote RWS 800 (max)

Tunnel PMTU checking disabled

Retransmission time 1, max 1 seconds

Unsent queuesize 0, max 0

Resend queuesize 0, max 1

Total resends 1, ZLB ACKs sent 2

Current nosession queue check 0 of 5

Retransmit time distribution: 0 3 1 0 0 0 0 0 0

Sessions disconnected due to lack of resources 0

%No active L2F tunnels

%No active PPTP tunnels

%No active PPPoE tunnels

EXEC command:

Device# show sgbp

Group Name: bri_pri Ref: 0x7B920584

Seed bid: default, 50, default seed bid setting

Member Name: rdt3640-17 State: active Id: 2

Ref: 0x73069C41

Address: 10.23.1.2

EXEC command:

Device# show isdn status

Global ISDN Switchtype = primary-5ess

ISDN Serial0:23 interface

dsl 0, interface ISDN Switchtype = primary-5ess

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED

Layer 3 Status:

2 Active Layer 3 Call(s)

CCB:callid=8008, sapi=0, ces=0, B-chan=23, calltype=DATA

CCB:callid=8009, sapi=0, ces=0, B-chan=22, calltype=DATA

Active dsl 0 CCBs = 2

The Free Channel Mask: 0x801FFFFF

Number of L2 Discards = 0, L2 Session ID = 0

Total Allocated ISDN CCBs = 2

Device# show user

Line User Host(s) Idle Location

* 0 con 0 idle 00:00:00

Interface User Mode Idle Peer

Address

Se0:20 Sync PPP -

Se0:21 Sync PPP -

Se0:22 Sync PPP -

Monitoring and Maintaining L2TP Large-Scale Dial-Out

To monitor and maintain L2TP large-scale dial-out, use the following EXEC commands:

Command

Purpose

Removes all dialer sessions and disconnects links.

Device# clear vpdn tunnel l2tp network-access-server gateway-name

Shuts down a specific tunnel and all the sessions within the tunnel.

Displays all dialer sessions.

Displays information about the virtual access interface, LCP, protocol states, and interface statistics. The status of the virtual access interface should be:

]]

Displays all static IP routes or those installed using the AAA route download function.

Displays MLP and Multichassis Multilink PPP (MMP) bundle information.

Displays a summary of all active VPDN tunnels.

]

Displays a summary of the relationships among VPDN groups and customer or VPDN profiles.

Note When you include the name of the VPDN group, the output displays information on domain or DNIS, tunnel endpoint, session limits, group priority, active sessions, group status, and reserved sessions.

Displays information about VPDN user failures.

Displays VPDN multilink information.

]

Displays VPDN session information including interface, tunnel, username, packets, status, and window statistics.

Displays VPDN tunnel information including tunnel protocol, ID, local and remote tunnel names, packets sent and received, tunnel, and transport status.

Configuration Examples

This section provides the following configuration examples:

- LNS Configured to Request Dial-Out Example

- LAC Configured to Accept Dial-Out Example

LNS Configured to Request Dial-Out Example

In the following example, the LNS VPDN group is configured to make a dial-out request using L2TP:

vpdn enable

!

vpdn group 2

request-dialout

protocol l2tp

rotary-group 1

local name group1

initiate-to ip 10.3.2.1 limit 5 priority 2

!

interface virtual-template 1

no ip directed-broadcast

encapsulation ppp

ppp multilink

!

interface Dialer 1

no ip directed-broadcast

dialer in-band

dialer vpdn

dialer aaa

dialer-group 1

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

dialer-list 1 protocol ip list 101

encapsulation ppp

ppp multilink

no fair-queue

ppp authentication chap

LAC Configured to Accept Dial-Out Example

In the following example, the VPDN group of a LAC is configured to accept dial-outs using L2TP as the tunneling protocol and dialer interface 2:

vpdn enable

!

vpdn group 1

accept-dialout

protocol l2tp

dialer 2

local name group2

terminate-from hostname host2

!

aaa new-model

aaa authentication ppp default radius local

aaa authorization network default radius none

aaa authorization configuration default radius

aaa route download 720

enable password 7 1236173C1B0F

!

username LAC1 password 7 030752180500

!

sgbp group dialbid

sgbp seed-bid offload

sgbp member LAC2 172.21.17.17

sgbp dial-bids

isdn switch-type basic-5ess

!

interface dialer 2

ip address 172.19.2.3 255.255.128

encapsulation ppp

dialer remote-name group1

dialer string 5551234

dialer aaa

dialer pool 1

dialer-group 1

ppp authentication chap

.

.

.

end

Command Reference

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2005–2009 CiscoOPDInc. All rights reserved.

Dial-Out DS0 Level Trunk Group

The Dial-Out DS0 Level Trunk Group feature directs an outbound synchronous or asynchronous call initiated by dial-on-demand routing (DDR) to use a specific channel of a T1 or E1 circuit.

Feature History for Dial-Out DS0 Level Trunk Group

Release

Modification

12.3(11)T

This feature was introduced.

Finding Support Information for Platforms and Cisco IOS Software Images

at the login dialog box and follow the instructions that appear.

Contents

- Prerequisites for Dial-Out DS0 Level Trunk Groups

- Restrictions for Dial-Out DS0 Level Trunk Groups

- Information About Dial-Out DS0 Level Trunk Groups

- How to Configure Dial-Out DS0 Level Trunk Groups and Enable for DDR

- Configuration Examples for Dial-Out DS0 Level Trunk Groups

- Additional References

- Command Reference

Prerequisites for Dial-Out DS0 Level Trunk Groups

You must be familiar with the Large-Scale Dial-Out feature before setting up and configuring dial-out trunk groups. See the “Related Documents” section for information about large-scale dial-out.

The Dial-Out DS0 Level Trunk Group feature has been tested for use on only the Cisco AS5800 series access servers.

Restrictions for Dial-Out DS0 Level Trunk Groups

- Dial-out trunk groups must be configured on a network access server (NAS).

- Each trunk group can consist of digital service 0s (DS0s) from various DS1s with similar signaling, but with the restriction that a single DS0 can belong to only one trunk group.

- Dial-out trunk groups are not supported for voice applications.

- Some trunk group features are also not supported for DDR, although the software will allow them to be configured. The following list of features should not be configured for trunk groups that are targeted by DDR:

– ISDN Two B Channel Transfer (TBCT) supplementary service

– Telephony Gateway Registration Protocol (TGREP) configuration

– Translation profiles

trunk group configuration command

trunk group configuration command

Information About Dial-Out DS0 Level Trunk Groups

You need to be familiar with the following concepts to use the Dial-Out DS0 Level Trunk Group feature:

- Dial-Out DS0 Level Trunk Group Outbound Call Control

- Dial-Out DS0 Level Trunk Group Aggregation Requirement

- Structure and Relationship of a Dial-Out DS0 Level Trunk Group

Dial-Out DS0 Level Trunk Group Outbound Call Control

In Cisco IOS software prior to Release 12.3(11)T, when a Cisco access gateway initiated a call (dial out triggered by interesting traffic), software controlled the DS1 link over which the call was placed for synchronous or asynchronous interfaces that used an appropriate dialer or a dial-out controller configuration, respectively.

Each DS1 has 24 DS0 channels framed together that can transfer data at 1.544 Mbps. DS0, also known as T1, is a digital interface that occurs as a single time slot on a DS1 and provides a 64-kbps, synchronous, full-duplex data channel.

The Dial-Out DS0 Level Trunk Group feature adds functionality that enhances outbound call routing by giving the user control over individual DS0s for outbound calls. Previous to this feature, outbound DS0s could not be configured separately from DS1s. The dial-out capabilities of a DS1 applied to all DS0s under that DS1.

Currently, the aggregation of DS1s into trunk groups is done using the Trunk Group Resource Manager (TGRM). The Dial-Out DS0 Level Trunk Group feature enables the TGRM subsystem to aggregate DS0s into trunk groups also. The dial-out capabilities of these DS0 trunk groups can then be configured directly at the DS0 level, using TGRM commands and by setting authentication, authorization, and accounting (AAA) attributes.

The configuration of DS0s for outbound calls enables the dial-on-demand feature to initiate outbound calls over a set of DS0s. DS0 is referred to as a B channel for ISDN Non-Facility Associated Signaling (NFAS) circuits and as a Circuit Identification Code (CIC) for Signaling System 7 (SS7).

Dial-out trunk groups are configured on an NAS. The feature provides the ability to direct an outbound synchronous or asynchronous call initiated by DDR to use a specific DS0 on one of the following circuits:

- PRI

- NFAS and SS7

- T1/CAS

- E1/R2

Note Although the tasks and examples in this document focus on T1 trunks, this feature also applies to E1 circuits.

Dial-Out DS0 Level Trunk Group Aggregation Requirement

The Dial-Out DS0 Level Trunk Group feature requires a scalable framework that can aggregate individual DS0s and make the groups available per user on dial out. Dial-out scalability was addressed by the framework of the Large-Scale Dial-Out feature, with a limitation that it was not possible to designate certain DS0s for dial out. This limitation became apparent for dial out over asynchronous lines that required a time-division multiplexing (TDM) cross-connect between an asynchronous device and the DS0 over which the call was finally placed.

The requirement to aggregate DS1s into trunk groups was met by the TGRM feature. TGRM now groups DS0s from various DS1s (which can be either T1 or E1 circuits). These DS0 trunk groups can then be used by DDR to control dial-out call capabilities at the DS0 level.

Dial-out trunk groups are actually an extension of the original TGRM framework, which had allowed a logical grouping of DS1s, but are enhanced in the Dial-Out DS0 Level Trunk Group feature to include individual DS0s from various DS1s. The main difference between the existing trunk groups and this enhancement is the manner by which trunk groups are used as targets by different applications. Voice applications use a trunk group that is a pool of DS1s, whereas DDR uses a dial-out trunk group that is a pool of DS0s or DS1s, or a mix of both.

The configuration by which DS0s are made part of a dial-out trunk group can be different for different signaling types. TGRM allocates the DS0s it manages using a hunt scheme such as round robin or least used. ISDN PRI interfaces can be configured to make the outgoing call selection in ascending or descending order. However, this configurable ISDN interface channel allocation scheme is overridden for DS0s that are managed by TGRM.

Structure and Relationship of a Dial-Out DS0 Level Trunk Group

Figure 1 shows the structure of a dial-out trunk group. Each trunk group can consist of DS0s from various signaling circuits, but with the restriction that a single DS0 can belong to only one trunk group.

Figure 1 Dial-Out DS0 Level Trunk Group Structure

Each dial-out trunk group is typically associated with one or more dial-out user profiles. Figure 2 shows various DS0s aggregated into trunk groups, which are referenced by dial-out profiles that reside on a AAA server.

Figure 2 Relationship of Dial-Out DS0 Level Trunk Groups to RADIUS Profiles

The dial-out trunk group configuration must be explicitly defined on the NAS and cannot be set up using other external components such as AAA, because they represent static functional configurations or configurable system resources on the NAS.

How to Configure Dial-Out DS0 Level Trunk Groups and Enable for DDR

This section contains tasks for configuring dial-out trunk groups and enabling them on DDR. Your network configuration will determine which of the following tasks you require:

- Configuring Dial-Out DS0 Level Trunk Groups on a DS1 Configured for CAS Signaling (required for CAS)

- Configuring Dial-Out DS0 Level Trunk Groups on an NFAS Member (required for NFAS/SS7)

- Configuring Dial-Out DS0 Level Trunk Groups on DS1 Configured for ISDN PRI (required for ISDN PRI)

- Associating DS0 Trunk Groups with Dialer (required for static configurations)

Configuring Dial-Out DS0 Level Trunk Groups on a DS1 Configured for CAS Signaling

You can configure single or multiple dial-out trunk groups on CAS. The following task shows how to configure a single dial-out trunk group. Repeat steps 4 through 6 to configure additional DS0 groups.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# controller t1 6/1

Configures a T1 or E1 controller and enters controller configuration mode.

Step 4

Router(config-controller)# ds0-group 4 timeslots 1-24

Defines channels for the CAS method by which the router connects to the PSTN.

Step 5

Router(config-controller)# cas-custom 4

Customizes signaling parameters for a particular E1 or T1 channel group on a channelized line.

Step 6

]]

Router(config-controller)# trunk-group label5 timeslots 1-24 preference 3

Directs an outbound synchronous or asynchronous call initiated by DDR to use specific DS0 channels of an ISDN circuit.

- timeslots timeslot-list —Selectively adds one or more DS0s from a signaling circuit to a trunk group. The timeslot-list argument accepts DS0s numbered from 1 to 24 for T1 links, and from 1 to 15 and 17 to 31 for E1 links.

- preference preference-number —Assigns a preference for DS0 members in a trunk group. Range is from 1 (highest preference) to 64 (lowest preference).

Step 7

exit

Router(config-controller)# exit

Exits the current configuration mode.

Configuring Dial-Out DS0 Level Trunk Groups on an NFAS Member

When NFAS or SS7 is used, signaling can take place over a circuit different than the one over which the data is being transported. The dial-out trunk group configuration is done in controller configuration mode. If a trunk groups is configured under an NFAS primary serial interface, all NFAS group interface member DS0s are added into the trunk groups. The NFAS primary serial interface will not have the time slot option enabled under its configuration mode.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# controller t1 6/1

Configures a T1 or E1 controller and enters controller configuration mode.

Step 4

Router(config-controller)# pri-group timeslots 1-24 nfas_d none nfas_int 2 nfas_group 0

Specifies an ISDN PRI group on a channelized T1 controller and releases the ISDN PRI signaling time slots.

- timeslot-range —A value or range of values for time slots on a T1 or E1 controller that consist of an ISDN PRI group. Use a hyphen to indicate a range.

Note Values and groups of time slot range values separated by commas (1,3-5,8-23, for example) are accepted.

- nfas_d none —The D-channel time slot is used as an additional B channel.

- nfas_int number —Specifies the provisioned NFAS interface as a value; value is a number from 0 to 8.

- nfas_group number —Specifies the NFAS group.

Step 5

]]

Router(config-controller)# trunk-group label5 timeslots 1-24 preference 3

Directs an outbound synchronous or asynchronous call initiated by DDR to use specific DS0 channels of an ISDN circuit.

- timeslots timeslot-list —Selectively adds one or more DS0s from a signaling circuit to a trunk group. The timeslot-list argument accepts DS0s numbered from 1 to 24 for T1 links, and from 1 to 15 and 17 to 31 for E1 links.

- preference preference-number —Assigns a preference for DS0 members in a trunk group. Range is from 1 (highest preference) to 64 (lowest preference).

Step 6

exit

Router(config-controller)# exit

Exits the current configuration mode.

Configuring Dial-Out DS0 Level Trunk Groups on DS1 Configured for ISDN PRI

The task in this section configures a dial-out trunk group on a PRI.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# controller t1 6/1

Configures an E1 or T1 controller and enters controller configuration mode.

Step 4

Router(config-controller)# framing esf

Selects the frame type for the data line.

- Framing type choices are as follows:

—Specifies super frame as the T1 frame type. This is the default.

—Specifies extended super frame as the T1 frame type.

—Specifies CRC4 frame as the E1 frame type. This is the default for Australia.

—Specifies no CRC4 frame as the E1 frame type.

(Optional)—Specifies the E1 frame type used in Australia.

Step 5

Router(config-controller)# linecode b8zs

Selects the line-code type for the data line.

- Line code type choices are as follows:

—Sp–ifies alternate mark inversion (AMI) as the line-code type. Valid for T1 or E1 controllers. This is the default for T1 lines.

—Sp–ifies B8ZS as the line-code type. Valid for T1 controller only.

—Sp–ifies high density bipolar 3 (HDB3) as the line-code type. Valid for E1 controller only. This is the default for E1 lines.

Step 6

Router(config-controller)# pri-group timeslots 3

Specifies an ISDN PRI group on a channelized T1 controller and releases the ISDN PRI signaling time slots.

- timeslot-range —A value or range of values for time slots on a T1 or E1 controller that consists of an ISDN PRI group. Use a hyphen to indicate a range.

Note Values and groups of time slot range values separated by commas (1,3-5,8-23, for example) are also accepted.

Step 7

]]

Router(config-controller)# trunk-group 15 timeslots 1,21-22 preference 1

Directs an outbound synchronous or asynchronous call initiated by DDR to use specific DS0 channels of an ISDN circuit.

- timeslots timeslot-list —Selectively adds one or more DS0s from a signaling circuit to a trunk group. The timeslot-list argument accepts DS0s numbered from 1 to 24 for T1 links, and from 1 to 15 and 17 to 31 for E1 links.

- preference preference-number —Assigns a preference for DS0 members in a trunk group. Range is from 1 (highest preference) to 64 (lowest preference).

Step 8

exit

Router(config-controller)# exit

Exits the current configuration mode.

Associating DS0 Trunk Groups with Dialer

command, or the large-scale dial-out framework can be used to download the trunk group identifier along with the dialer string. The task in this section shows how to set up a static dial-out configuration for DDR over DS0 trunk groups, and is done by configuring a dialer interface, setting up a profile on the AAA server, and applying a static dial-out trunk configuration on an NAS.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# controller t1 6/1

Configures an E1 or T1 controller and enters controller configuration mode.

Step 4

Router(config-controller)# framing esf

Selects the frame type for the data line.

- Framing type choices are as follows:

—Specifies super frame as the T1 frame type. This is the default.

—Specifies extended super frame as the T1 frame type.

—Specifies CRC4 frame as the E1 frame type. This is the default for Australia.

—Specifies no CRC4 frame as the E1 frame type.

(Optional)—Specifies the E1 frame type used in Australia.

Step 5

Router(config-controller)# linecode b8zs

Selects the line-code type for the data line.

- Line code type choices are as follows:

—Sp–ifies AMI as the line-code type. Valid for T1 or E1 controllers. This is the default for T1 lines.

—Sp–ifies B8ZS as the line-code type. Valid for T1 controller only.

—Sp–ifies high density bipolar 3 (HDB3) as the line-code type. Valid for E1 controller only. This is the default for E1 lines.

Step 6

Router(config-controller)# pri-group timeslots 3

Specifies an ISDN PRI group on a channelized T1 controller and releases the ISDN PRI signaling time slots.

- timeslot-range —A value or range of values for time slots on a T1 or E1 controller that consists of an ISDN PRI group. Use a hyphen to indicate a range.

Note Values and groups of time slot ranges separated by commas (1,3-5,8-23, for example) are also accepted.

Step 7

]]

Router(config-controller)# trunk-group 15 timeslots 1,21-22 preference 1

Directs an outbound synchronous or asynchronous call initiated by DDR to use specific DS0 channels of an ISDN circuit.

- timeslots timeslot-list —Selectively adds one or more DS0s from a signaling circuit to a trunk group. The timeslot-list argument accepts DS0s numbered from 1 to 24 for T1 links, and from 1 to 15 and 17 to 31 for E1 links.

- preference preference-number —Assigns a preference for DS0 members in a trunk group. Range is from 1 (highest preference) to 64 (lowest preference).

command statements can be made in static configurations.

Step 8

exit

Router(config-controller)# exit

Exits the current configuration mode.

Step 9

Router(config)# interface dialer 0

Defines a dialer rotary group and enters interface configuration mode.

Step 10

Router(config-if)# dialer string rotary1 trunkgroup trunk1

Specifies the telephone number to be dialed and a dial-out trunk group name for a static configuration on an NAS.

Step 11

]

Router(config-if)# dialer aaa suffix @ciscoDDR password cisco

Allows a dialer to access the AAA server for dialing information.

Step 12

exit

Router(config-if)# exit

Exits the current configuration mode.

What to Do Next

Use the following dial-out trunk group statements in the profile file that sets up the AAA server to apply a static dial-out DS0 trunk configuration on an NAS.

RADIUS VSA

trunkgroup = trunk1

AAA Cisco-AVPair

"

dialout-out Password="cisco"

Cisco-AVPair = "outbound:trunkgroup=16"

.

.

.

Note The trunk group specified in the RADIUS vendor-specific attribute (VSA) must match the name defined in the trunk group configuration.

Configuration Examples for Dial-Out DS0 Level Trunk Groups

This section contains the following configuration examples:

- Configure a Dial-Out DS0 Level Trunk Group on a DS1 Configured for CAS: Example

- Configure Multiple Dial-Out DS0 Level Trunk Groups on a PRI Trunk: Example

- Configure Dial-Out DS0 Level Trunk Groups on an NFAS Group: Example

- Configure Dial-Out DS0 Level Trunk Groups in a Dialer Rotary Group: Examples

- Associating a DS0 Trunk Group with a Dialer for DDR: Example

Configure a Dial-Out DS0 Level Trunk Group on a DS1 Configured for CAS: Example

The following example shows how to configure a single DS0 group on a CAS:

controller t1 0

ds0-group 2 timeslots 1-24

cas-custom 2

trunk-group label3 timeslots 1-12

trunk-group label4 timeslots 13-24 preference 2

controller t1 2

ds0-group 4 timeslots 1-24

cas-custom 4

trunk-group label5 timeslots 1-24 preference

Configure Multiple Dial-Out DS0 Level Trunk Groups on a PRI Trunk: Example

The following example shows how to configure B channels from a PRI channel into a DS0 trunk group:

controller T1 0

pri-group timeslots 1-24

trunk-group L1 timeslots 1-5 preference 10

!

The following example shows how to include all the B channels of the PRI channel into a trunk group:

interface serial 0:23

trunk-group L2 20

Note The trunk group configuration under the PRI channel and the controller are mutually exclusive.

Configure Dial-Out DS0 Level Trunk Groups on an NFAS Group: Example

option is not available in the serial interface configuration mode, because a serial interface may represent an NFAS serial interface.

controller T1 0

pri-group timeslots 1-24 nfas_d primary nfas_int 0 nfas_group 0

trunk-group L1 timeslots 1-5 preference 1

trunk-group L2 timeslots 12-14 preference 2

!

controller T1 1

pri-group timeslots 1-24 nfas_d backup nfas_int 1 nfas_group 0

trunk-group L3 timeslots 1-5

trunk-group L4 timeslots 12-14 preference 4

!

controller T1 3

pri-group timeslots 1-24 nfas_d none nfas_int 2 nfas_group 0

trunk-group L5 timeslots 7,9,11

trunk-group L6 timeslots 2,4,6,14-16 preference 6

The following example shows how to include all the B channels of the PRI channel into a trunk group:

interface serial 0:23

trunk-group trunk5 20

Note The trunk group configuration under the NFAS group member and the corresponding NFAS member serial interface are mutually exclusive.

Configure Dial-Out DS0 Level Trunk Groups in a Dialer Rotary Group: Examples

In the following examples, dial-out trunk groups 15 and 16 have DS0s from PRI interfaces 0:23 and 6:23. These interfaces are also rotary members of dialer interface 0. The AAA profile named dialout-out refers to trunk group 16, implying that a DS0 from trunk group 16 will be assigned for the outgoing call for this user using the dialout-out profile.

dialout-out Password="cisco"

Cisco-AVPair = "outbound:trunkgroup=16"

Service-Type = Outbound,

Cisco-AVPair = "outbound:addr*10.121.94.254",

Cisco-AVPair = "Outbound:dial-number=5550101",

RAS-5400-1 Password="cisco"

Service-Type = Outbound,

Framed-Route="10.121.94.254/32 Dialer0 200 name dialout"

Framed-Route="10.121.94.0/24 10.121.94.254 200"

controller T1 0

pri-group timeslots 1-24

trunk-group 16 timeslots 1,21-22 preference 1

trunk-group 15 timeslots 18-19

.

.

.

interface serial 0:23

dialer rotary-group 0

controller T1 6

pri-group timeslots 1-24

trunk-group 16 timeslots 21-22

trunk-group 15 timeslots 18-19 preference 2

.

.

.

interface serial 6:23

dialer rotary-group 0

interface dialer 0

dialer aaa

In the following examples, trunk group 15 has member DS0s from PRI interfaces 0:23, 6:23, and 7:23. PRI interfaces 6:23, and 7:23 are assigned to the same rotary group. When an outgoing call is placed through interface dialer 0, TGRM could return a DS0 that belongs to PRI interfaces 6:23, 7:23, or 0:23. But because PRI interfaces 0:23 are not rotary members of interface dialer 0, the call would fail.

dialout-out Password="cisco"

Cisco-AVPair = "outbound:trunkgroup=16"

Service-Type = Outbound,

Cisco-AVPair = "outbound:addr*10.121.94.254",

Cisco-AVPair = "Outbound:dial-number=5550101",

RAS-5400-1 Password="cisco"

Service-Type = Outbound,

Framed-Route="10.121.94.254/32 Dialer0 200 name dialout"

Framed-Route="10.121.94.0/24 10.121.94.254 200"

.

.

.

controller t1 0

pri-group timeslots 1-24

trunk-group 15 timeslots 1,21-22 preference 1

trunk-group 16 timeslots 18-19

interface serial 0:23

dialer rotary-group 0

controller t1 6

pri-group timeslots 1-24

trunk-group 15 timeslots 21-22

trunk-group 16 timeslots 18-19 preference 2

interface serial 6:23

dialer rotary-group 1

controller t1 7

pri-group timeslots 1-24

trunk-group 15 timeslots 18-19

interface serial 7:23

dialer rotary-group 1

interface dialer 0

dialer aaa

Associating a DS0 Trunk Group with a Dialer for DDR: Example

The following example shows the configurations needed to apply a static dial-out trunk group:

interface dialer 0

dialer string 5550101 trunkgroup 16

controller T1 6/1

framing esf

linecode b8zs

pri-group timeslots 1-24

trunk-group 16 timeslots 1,21-22 preference 1

trunk-group 15 timeslots 18-19

Additional References

The following sections provide references related to dial-out trunk groups.

Related Documents

Related Topic

Document Title

Large-scale dial-out

ISDN signaling circuits

ISDN signaling circuit and large-scale dial-out commands, including syntax and examples

Standards

Standards

Title

None

—

MIBs

MIBs

MIBs Link

None

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

RFCs

RFCs

Title

None

—

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

Command Reference

.

New Commands

- dialer string trunkgroup

- trunk-group (timeslots)

Modified Command

- show trunk group

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007–2009 Cisco Systems, Inc. All rights reserved.

L2TP Large-Scale Dial-Out

Feature History

Release

Modification

12.2(4)T

This feature was introduced.

12.2(11)T

This feature was implemented on Cisco access server platforms.

This document describes the L2TP Large-Scale Dial-Out feature. It includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Configuration Tasks

- Monitoring and Maintaining L2TP Large-Scale Dial-Out

- Configuration Examples

- Command Reference

Feature Overview

The Asynchronous Line Monitoring feature feature enables the router to dial multiple Layer 2 Tunnel Protocol (L2TP) access concentrators (LACs) from a single L2TP network server (LNS). The LACs are signaled through the LNS and use L2TP to establish the dial sessions. User-defined profiles can be configured on an authentication, authorization, and accounting (AAA) server and retrieved by the LNS when dial-out occurs.The Asynchronous Line Monitoring feature feature also supports multiple LACs bound into one stack group, call traffic load balancing, and outbound call congestion management.

Figure 1 provides an example of L2TP large-scale dial-out session startup. Each part of the process is numbered and described in text following the figure.

Figure 1 Sample Scenario L2TP Large-Scale Dial-Out Session

1. The IP packets arrive at the LNS and are forwarded to the dialer interface by the routing protocol. (A virtual access interface has not been created yet.)

2. A dialer session is created and placed in a pending state while the dialer interface sends a Dial Out Request message to the AAA server requesting the user profile. The AAA server sends the user profile, and the LNS builds a dynamic map based on the reply.

3. The dialer interface looks for its dial resources and finds the virtual private dialup network (VPDN) group. The dialer interface then issues a dial call request to the VPDN group, which creates a virtual access interface. The virtual access interface becomes a member of a rotary group.

4. If there is no existing L2TP tunnel between the LNS and the primary LAC, the LNS would establish one; otherwise, it uses the existing tunnel. The LNS sends an Outgoing Call ReQuest (OCRQ) message, inside of which is the dynamic dialer map, to the primary LAC.

5. Upon receiving the OCRQ message, the primary LAC determines whether it is congested. If the primary LAC is congested, it sends a Stack Group Bidding Protocol (SGBP) Discover message through a new tunnel to the secondary LAC in the scenario depicted in Figure 1, but it could send the message to any other LAC configured in the SGBP stack group.

After the secondary LAC receives the SGBP Discover message from the LNS, it responds with an SGBP Offer message describing available resources.

6. If neither LAC has resources to dial out, the primary LAC would send a Call Disconnect Notification (CDN) message to the LNS. The LNS would then tear down the tunnel.

If the secondary LAC has more resources, the primary LAC can choose to dial through the secondary LAC. The primary LAC sends a CDN message to the LNS with error code 7, which means “Try another” as defined in RFC 2661. Inside this message, the LNS learns that its dial-out request should be redirected to the secondary LAC, and the LNS clears the session to the primary LAC.

7. The LNS creates a new tunnel to the secondary LAC if one does not exist. The dial-out LAC creates a VPDN session and sets it in a pending state. It then places a call to the PPP client. Once the call is connected, the LAC determines to which pending VPDN session the connected interface belongs and binds the connected interface with the session. The secondary LAC sends an Outgoing Call Connected (OCCN) message to the LNS. The LNS determines for which pending virtual access interface and VPDN session this OCCN is meant, and then the LNS brings up the virtual access interface.

Benefits

Large-Scale Dial-Out Integrated with L2TP

Before Cisco IOS Release 12.2(4)T, L2TP required that requests for tunneled dial-out calls be from a single LNS to a single LAC, and that configurations be available on the local server. The Asynchronous Line Monitoring feature feature introduced in Cisco IOS Release 12.2(4)T allows dialing multiple LACs from a single LNS. The LACs are signaled through the LNS using L2TP to establish the dial sessions. User-defined profiles can also be configured on a AAA server and retrieved by the LNS when dial-out occurs.

Enhanced Dial Management

The Asynchronous Line Monitoring feature feature also provides the following benefits:

- Multiple LACs bound into one stack group

- Call traffic load balancing

- Outbound call congestion management

Related Features and Technologies

, Release 12.2. Refer to the chapter “Configuring Virtual Private Networks” in the part “Virtual Templates, Profiles, and Networks,” and the chapter “Configuring Large-Scale Dial-Out” in the part “Dial Access Specialized Features.”

Supported Platforms

See the next section for information about Feature Navigator and how to use this tool to determine the platforms and software images in which this feature is available.

Platform Support Through Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Feature Navigator. Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image.

To access Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions at http://www.cisco.com/register.

Feature Navigator is updated when major Cisco IOS software releases and technology releases occur. As of May 2001, Feature Navigator supports M, T, E, S, and ST releases. You can access Feature Navigator at the following URL:

http://www.cisco.com/go/fn

Supported Standards, MIBs, and RFCs

Standards

None

MIBs

None

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

RFCs

- RFC 2661, Layer Two Tunneling Protocol (L2TP )

Configuration Tasks

See the following sections for configuration tasks for the Asynchronous Line Monitoring feature feature. Each task in the list is identified as either required or optional:

- Configuring the LNS to Request Dial-Out (required)

- Configuring a LAC to Accept Dial-Out (required)

Configuring the LNS to Request Dial-Out

Virtual profiles depend on PPP authentication; therefore the LNS must authenticate the connection to use virtual profiles.

, Release 12.2, describes the commands to configure AAA.

You also need to configure your LNS to communicate with the applicable security server, either a TACACS+ or RADIUS daemon.

, Release 12.2.

, Release 12.2.

To configure the LNS to request dial-out tunneled PPP connections from a LAC, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Enables VPDN and directs the router to look for tunnel definitions on a remote authorization server.

Step 2

Creates VPDN group 1 and enters VPDN group configuration mode.

Step 3

Enters VPDN request-dialout group configuration mode and enables the tunnel server to send L2TP dial-out requests.

Step 4

Specifies L2TP as the tunneling protocol.

Note L2TP is the only protocol that supports dial-out.

Step 5

Specifies the dialer rotary group that will be used to dial out.

Note You can configure only one dialer rotary group. Attempting to configure a second dialer resource will remove the first from the configuration.

Step 6

Specifies the number of the virtual template that will be used to clone the virtual access interface.

Step 7

Returns to VPDN group configuration mode.

Step 8

Specifies the IP address that will be dialed out. This is the IP address of the LAC.
keywords are not available for VPDN dial-out.

Step 9

Specifies that the L2TP tunnel will identify itself with this host name.

Step 10

Returns to global configuration mode.

Step 11

Specifies the number of the virtual template that will be used to clone the virtual access interface. Enters interface configuration mode so that you can set the configuration parameters that you want applied to virtual access interfaces.

Step 12

Creates a virtual template interface that can be configured and applied dynamically in creating virtual access interfaces.

Step 13

Device(config-if)# no ip directed-broadcast

Disables the translation of a directed broadcast to physical broadcasts.

Step 14

Sets the PPP encapsulation method on the interface.

Step 15

Device(config-if)# ppp multilink

Enables Multilink PPP (MLP) on an interface.

Step 16

Returns to global configuration mode.

Step 17

Device(config)# aaa new-model

Enables AAA access control .

Step 18

Specifies one or more AAA authentication methods for use on serial interfaces that are running PPP. Refer to the Cisco IOS security guides for specific authentication arguments for your network security configuration.

Step 19

Sets parameters that restrict user access to a network. Refer to the Cisco IOS security guides for specific authentication arguments for your network security configuration.

Step 20

Enters interface configuration mode for dialer interface 1.

Step 21

Device(config-if)# dialer in-band

Specifies that DDR is to be supported.

Step 22

Device(config-if)# dialer vpdn

Enables a dialer profile to use L2TP dial-out.

Step 23

Allows a dialer to access the AAA server for dialing information or, optionally, specifies a suffix and nondefault password for authentication.

Step 24

Device(config-if)# no ip directed-broadcast

Disables the translation of a directed broadcast to physical broadcasts.

Step 25

Controls access by configuring an interface to belong to a specific dialing group.

Step 26

}

Defines a DDR dialer list to control dialing by protocol or by a combination of a protocol and a previously defined access list.

Step 27

Sets the PPP encapsulation method on the dialer interface.

Step 28

Device(config-if)# ppp multilink

Enables MLP on an interface.

, Release 12.2, for more information.

See the configuration examples later in this document for additional commands that may be configured on the LAC.

Configuring a LAC to Accept Dial-Out

, Release 12.2, describes the commands to configure a stack group.

Additionally, the information about configuring network security in the section “Configuring the LNS to Request Dial-Out” of this document also applies to configuring the LAC.

To configure a LAC to accept tunneled dial-out connections from the LNS, use the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Enables VPDN and directs the router to look for tunnel definitions on a remote authorization server.

Step 2

Creates VPDN group 1 and enters VPDN group configuration mode.

Step 3

Enters VPDN accept-dialout group configuration mode and enables the NAS to accept L2TP dial-out requests.

Step 4

Specifies L2TP as the tunneling protocol.

Note L2TP is the only protocol that supports dial-out.

Step 5

Specifies the dialer that is used to dial out to the client.

Step 6

Returns to VPDN group configuration mode.

Step 7

]

Specifies the IP address that will be tunneled to.

Step 8

Specifies that the L2TP tunnel will identify itself with this host name.

Step 9

Returns to global configuration mode.

Step 10

Device(config)# aaa new-model

Enables the AAA access control model.

Step 11

Specifies one or more AAA authentication methods for use on serial interfaces that are running PPP. Refer to the Cisco IOS security guides for specific authentication arguments for your network security configuration.

Step 12

Sets parameters that restrict user access to a network. Refer to the Cisco IOS security guides for specific authorization arguments for your network security configuration.

Step 13

Creates authentication credentials for the stack group.

Step 14

Creates the stack group and assigns this router to it.

Step 15

]

Specifies a peer member of the stack group.

Step 16

Enters interface configuration mode for dialer interface 1.

Step 17

Device(config-if)# dialer aaa

Allows a dialer to access the AAA server for dialing information.

Step 18

Device(config-if)# dialer in-band

Specifies that DDR is to be supported.

Step 19

Device(config-if)# no ip directed-broadcast

Disables the translation of a directed broadcast to physical broadcasts.

Step 20

Sets the PPP encapsulation method on the dialer interface.

Step 21

Device(config-if)# ppp multilink

Enables MLP on an interface.

See the configuration examples later in this document for additional commands that may be configured on the LAC.

Verifying L2TP Large-Scale Dial-Out

To verify that L2TP large-scale dial-out is configured correctly, perform the following steps:

Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.

EXEC commands:

Device# show vpdn

L2TP Tunnel and Session Information Total tunnels 1 sessions 1

LocID RemID Remote Name State Remote Address Port Sessions

55788 55043 rdt5300-15 est 10.23.1.1 1701 1

LocID RemID TunID Intf Username State Last Chg

Fastswitch

83 50 55788 Vi1 rdt7204-1 est 00:01:08

enabled

%No active L2F tunnels

%No active PPTP tunnels

%No active PPPoE tunnels

Device# show vpdn tunnel all

L2TP Tunnel Information Total tunnels 1 sessions 1

Tunnel id 8873 is up, remote id is 41736, 1 active sessions

Tunnel state is established, time since change 00:00:05

Remote tunnel name is rdt5300-15

Internet Address 10.23.1.1, port 1701

Local tunnel name is rdt7206vxr-8

Internet Address 10.23.1.100, port 1701

11 packets sent, 12 received

653 bytes sent, 666 received

Control Ns 3, Nr 3

Local RWS 10000 (default), Remote RWS 800

Tunnel PMTU checking disabled

Retransmission time 1, max 1 seconds

Unsent queuesize 0, max 0

Resend queuesize 0, max 2

Total resends 0, ZLB ACKs sent 2

Current nosession queue check 0 of 5

Retransmit time distribution: 0 2 0 0 0 0 0 0 0

Sessions disconnected due to lack of resources 0

%No active L2F tunnels

%No active PPTP tunnels

%No active PPPoE tunnels

EXEC command to verify that the interface is up and that no errors are reported:

Device# show interfaces virtual-access 1

Virtual-Access1 is up, line protocol is up

Hardware is Virtual Access interface

MTU 1500 bytes, BW 64 Kbit, DLY 100000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation PPP, loopback not set

DTR is pulsed for 5 seconds on reset

Time to interface disconnect: idle 00:01:16

Interface is bound to Di1 (Encapsulation PPP)

LCP Open, multilink Open

Open: IPCP, CDPCP

Last input 00:00:07, output never, output hang never

Last clearing of "show interface" counters 00:01:33

Input queue: 0/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/1/16 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

Available Bandwidth 48 kilobits/sec

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

9 packets input, 767 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

10 packets output, 849 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

EXEC command:

Device# show ppp multilink

Virtual-Access3, bundle name is rdt7204-1

Bundle up for 00:01:19

Using relaxed lost fragment detection algorithm.

Dialer interface is Dialer1

0 lost fragments, 0 reordered, 0 unassigned

0 discarded, 0 lost received, 1/255 load

0x8 received sequence, 0x8 sent sequence

Member links: 4 (max not set, min not set)

rdt5300-15:Virtual-Access1 (10.23.1.1), since 00:01:19, last rcvd seq

000006, unsequenced

rdt5300-15:Virtual-Access5 (10.23.1.1), since 00:01:18, last rcvd seq

000007, unsequenced

rdt5300-15:Virtual-Access4 (10.23.1.1), since 00:00:48, no frags rcvd,

unsequenced

rdt5300-15:Virtual-Access6 (10.23.1.1), since 00:00:18, no frags rcvd,

unsequenced

EXEC commands:

Device# show vpdn

L2TP Tunnel and Session Information Total tunnels 1 sessions 1

LocID RemID Remote Name State Remote Address Port Sessions

51111 46115 rdt7206vxr-8 est 10.23.1.100 1701 1

LocID RemID TunID Intf Username State Last Chg

Fastswitch

2 86 51111 Se0:22 rdt7204-1 est 00:00:05

enabled

%No active L2F tunnels

%No active PPTP tunnels

%No active PPPoE tunnels

Device# show vpdn tunnel all

L2TP Tunnel Information Total tunnels 1 sessions 1

Tunnel id 51111 is up, remote id is 46115, 1 active sessions

Tunnel state is established, time since change 00:00:18

Remote tunnel name is rdt7206vxr-8

Internet Address 10.23.1.100, port 1701

Local tunnel name is rdt5300-15

Internet Address 10.23.1.1, port 1701

13 packets sent, 12 received

1156 bytes sent, 677 received

Control Ns 3, Nr 3

Local RWS 800 (default), Remote RWS 800 (max)

Tunnel PMTU checking disabled

Retransmission time 1, max 1 seconds

Unsent queuesize 0, max 0

Resend queuesize 0, max 1

Total resends 1, ZLB ACKs sent 2

Current nosession queue check 0 of 5

Retransmit time distribution: 0 3 1 0 0 0 0 0 0

Sessions disconnected due to lack of resources 0

%No active L2F tunnels

%No active PPTP tunnels

%No active PPPoE tunnels

EXEC command:

Device# show sgbp

Group Name: bri_pri Ref: 0x7B920584

Seed bid: default, 50, default seed bid setting

Member Name: rdt3640-17 State: active Id: 2

Ref: 0x73069C41

Address: 10.23.1.2

EXEC command:

Device# show isdn status

Global ISDN Switchtype = primary-5ess

ISDN Serial0:23 interface

dsl 0, interface ISDN Switchtype = primary-5ess

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED

Layer 3 Status:

2 Active Layer 3 Call(s)

CCB:callid=8008, sapi=0, ces=0, B-chan=23, calltype=DATA

CCB:callid=8009, sapi=0, ces=0, B-chan=22, calltype=DATA

Active dsl 0 CCBs = 2

The Free Channel Mask: 0x801FFFFF

Number of L2 Discards = 0, L2 Session ID = 0

Total Allocated ISDN CCBs = 2

Device# show user

Line User Host(s) Idle Location

* 0 con 0 idle 00:00:00

Interface User Mode Idle Peer

Address

Se0:20 Sync PPP -

Se0:21 Sync PPP -

Se0:22 Sync PPP -

Monitoring and Maintaining L2TP Large-Scale Dial-Out

To monitor and maintain L2TP large-scale dial-out, use the following EXEC commands:

Command

Purpose

Removes all dialer sessions and disconnects links.

Device# clear vpdn tunnel l2tp network-access-server gateway-name

Shuts down a specific tunnel and all the sessions within the tunnel.

Displays all dialer sessions.

Displays information about the virtual access interface, LCP, protocol states, and interface statistics. The status of the virtual access interface should be:

]]

Displays all static IP routes or those installed using the AAA route download function.

Displays MLP and Multichassis Multilink PPP (MMP) bundle information.

Displays a summary of all active VPDN tunnels.

]

Displays a summary of the relationships among VPDN groups and customer or VPDN profiles.

Note When you include the name of the VPDN group, the output displays information on domain or DNIS, tunnel endpoint, session limits, group priority, active sessions, group status, and reserved sessions.

Displays information about VPDN user failures.

Displays VPDN multilink information.

]

Displays VPDN session information including interface, tunnel, username, packets, status, and window statistics.

Displays VPDN tunnel information including tunnel protocol, ID, local and remote tunnel names, packets sent and received, tunnel, and transport status.

Configuration Examples

This section provides the following configuration examples:

- LNS Configured to Request Dial-Out Example

- LAC Configured to Accept Dial-Out Example

LNS Configured to Request Dial-Out Example

In the following example, the LNS VPDN group is configured to make a dial-out request using L2TP:

vpdn enable

!

vpdn group 2

request-dialout

protocol l2tp

rotary-group 1

local name group1

initiate-to ip 10.3.2.1 limit 5 priority 2

!

interface virtual-template 1

no ip directed-broadcast

encapsulation ppp

ppp multilink

!

interface Dialer 1

no ip directed-broadcast

dialer in-band

dialer vpdn

dialer aaa

dialer-group 1

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

dialer-list 1 protocol ip list 101

encapsulation ppp

ppp multilink

no fair-queue

ppp authentication chap

LAC Configured to Accept Dial-Out Example

In the following example, the VPDN group of a LAC is configured to accept dial-outs using L2TP as the tunneling protocol and dialer interface 2:

vpdn enable

!

vpdn group 1

accept-dialout

protocol l2tp

dialer 2

local name group2

terminate-from hostname host2

!

aaa new-model

aaa authentication ppp default radius local

aaa authorization network default radius none

aaa authorization configuration default radius

aaa route download 720

enable password 7 1236173C1B0F

!

username LAC1 password 7 030752180500

!

sgbp group dialbid

sgbp seed-bid offload

sgbp member LAC2 172.21.17.17

sgbp dial-bids

isdn switch-type basic-5ess

!

interface dialer 2

ip address 172.19.2.3 255.255.128

encapsulation ppp

dialer remote-name group1

dialer string 5551234

dialer aaa

dialer pool 1

dialer-group 1

ppp authentication chap

.

.

.

end

Command Reference

.

- xremote

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001–2009 Cisco Systems, Inc. All rights reserved.

L2TP Large-Scale Dial-Out per-User Attribute via AAA

First Published: March 16, 2012

Last Updated: November 20, 2014

This feature makes it possible for IP per-user attributes to be applied to a Layer 2 Tunneling Protocol (L2TP) dial-out session.

Feature Specifications for L2TP Large-Scale Dial-Out per-User Attribute via AAA

Feature History

Release

Modification

12.2(15)T

This feature was introduced.

Cisco IOS Release XE 3.9S

In Cisco IOS XE Release 3.9S, support was added for the Cisco CSR 1000V.

Supported Platforms

Cisco 7200, Cisco 7400

Finding Support Information for Platforms and Cisco IOS Software Images

at the login dialog box and follow the instructions that appear.

Contents

- Restrictions for Using L2TP Large-Scale Dial-Out per-User Attribute via AAA

- Information About L2TP Large-Scale Dial-Out per-User Attribute via AAA

- How to Configure L2TP Large-Scale Dial-Out per-User Attribute via AAA

- Configuration Examples for L2TP Large-Scale Dial-Out per-User Attribute via AAA

- Additional References

- Command Reference

Restrictions for Using L2TP Large-Scale Dial-Out per-User Attribute via AAA

support the following features associated with L2TP dial-out:

- Dialer Watch

- Dialer backup

- Dialer redial

- Dialer multiple number dial

- Callback initiated by an L2TP network server (LNS), the Bandwidth Allocation Protocol (BAP), and so on

Information About L2TP Large-Scale Dial-Out per-User Attribute via AAA

To configure the L2TP Large-Scale Dial-Out per-User Attribute via AAA feature, you need to understand the following concept:

- How the L2TP Large-Scale Dial-Out per-User Attribute via AAA Feature Works

How the L2TP Large-Scale Dial-Out per-User Attribute via AAA Feature Works

The L2TP Large-Scale Dial-Out per-User Attribute via AAA feature makes it possible for IP and other per-user attributes to be applied to an L2TP dial-out session from an LNS. Before this feature was released, IP per-user configurations from authentication, authorization, and accounting (AAA) servers were not supported; the IP configuration would come from the dialer interface defined on the device.

The L2TP Large-Scale Dial-Out per-User Attribute via AAA feature works in a way similar to virtual profiles and L2TP dial-in. The L2TP virtual access interface is first cloned from the virtual template, which means that configurations from the virtual template interface will be applied to the L2TP virtual access interface. After authentication, the AAA per-user configuration is applied to the virtual access interface. Because AAA per-user attributes are applied only after the user has been authenticated, the LNS must be configured to authenticate the dial-out user (configuration authentication is needed for this feature).

With the L2TP Large-Scale Dial-Out per-User Attribute via AAA feature, all software components can now use the configuration present on the virtual access interface rather than what is present on the dialer interface. For example, IP Control Protocol (IPCP) address negotiation uses the local address of the virtual access interface as the device address while negotiating with the peer.

All Cisco IOS commands that can be configured as AAA per-user commands are supported by the L2TP Large-Scale Dial-Out per-User Attribute via AAA feature. Following is a list of some of the commands that are typically configured on a per-user basis:

- The ip vrf forwarding interface configuration command

- The ip unnumbered loopback0 interface configuration command

- Per-user static routes

- Access lists

- Multilink bundles

- Idle timers

How to Configure L2TP Large-Scale Dial-Out per-User Attribute via AAA

This section contains the following procedures:

- Configuring the VPDN Group on the LNS (required)

- Verifying the Configuration on the Virtual Access Interface (optional)

- Troubleshooting the Configuration on the Virtual Access Interface (optional)

Configuring the VPDN Group on the LNS

You will need to configure the virtual template under the request dial-out configuration. You will also need to select the tunneling protocol and assign the virtual private dial-up network (VPDN) subgroup to a rotary group.

AAA per-user configuration is supported only on legacy dialer or dialer rotary groups and does not make sense on dialer profiles.

Be sure to configure the virtual template so that the LNS authenticates the dial-out user.

If a virtual template is not configured, L2TP dial-out per-user is not supported, but the configuration is backward compatible for all IP configurations that come from the dialer interface.

Prerequisites

The L2TP Large-Scale Dial-Out per-User Attribute via AAA feature provides additional functionality for large-scale dial-out networks and Layer 2 tunneling. It is assumed that a network is already configured and operational, and that the tasks in this document will be performed on an operational network. See the “Additional References” section for more information about large-scale dial-out networks, Layer 2 tunneling, and virtual template interfaces.

Restrictions

If the tasks in this section are not performed, the software will operate in the original mode, that is, IP per-user configurations from a AAA server will not be recognized and IP addresses will come from the dialer interface defined on the device.

To configure the VPDN group that makes it possible for IP per-user attributes to be applied to an L2TP dial-out session, use the following commands:

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Device# configure terminal

Enters global configuration mode.

Step 3

Device(config)# vpdn-group 1

Creates a VPDN group and starts VPDN group configuration mode.

Step 4

Device(config-vpdn)# request-dialout

Enables an LNS to request VPDN dial-out calls by using L2TP, and starts VPDN request-dialout configuration mode.

Step 5

Device(config-vpdn-req-ou)# protocol l2tp

Specifies the L2TP tunneling protocol.

Step 6

Device(config-vpdn-req-ou)# rotary-group 1

Assigns a request-dialout VPDN subgroup to a dialer rotary group.

Step 7

Device(config-vpdn-req-ou)# virtual-template 1

Clones the configuration from a corresponding virtual template interface, and supports IP per-user configurations from a AAA server.

Step 8

Device(config-vpdn-req-ou)# exit

Exits VPDN request-dialout configuration mode.

What to Do Next

The configuration for the L2TP Large-Scale Dial-Out per-User Attribute via AAA feature must include a AAA profile to specify the per-user attributes. See the “Per-User AAA Attributes Profile Example” for an example of such a profile.

Verifying the Configuration on the Virtual Access Interface

This task verifies that the per-user AAA commands are successfully parsed on the virtual access interface.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

]

Device# show interfaces virtual-access 3 configuration

Displays status, traffic data, and configuration information about a specified virtual access interface.

- configuration —(Optional) Restricts output to configuration information.

Troubleshooting the Configuration on the Virtual Access Interface

This task displays additional information about the per-user AAA commands that are parsed on the virtual access interface.

SUMMARY STEPS

1. Attach a console directly to a device.

5. Use Telnet to access a device port and repeat Steps 2 and 3.

DETAILED STEPS

Command or Action

Purpose

Step 1

Attach a console directly to a device.

—

Step 2

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 3

Device# configure terminal

Enters global configuration mode.

Step 4

Disables all logging to the console terminal.

- To reenable logging to the console, use the logging console command in global configuration mode.

Step 5

Use Telnet to access a Device port and repeat Steps 2 and 3.

Enters global configuration mode in a recursive Telnet session, which allows the output to be redirected away from the console port.

Step 6

Enables logging output on the virtual terminal.

Step 7

Exits to privileged EXEC mode.

Step 8

Device# debug aaa per-user

Displays what attributes are applied to each user as the user authenticates.

Step 9

Device# debug vtemplate events

Displays the virtual template events to form a virtual access interface.

Step 10

Device# debug vtemplate cloning

Displays the virtual template cloning to form a virtual access interface.

- Use this command to verify when the interface is created (cloned from the virtual template) at the beginning of the dialup connection and when the interface is destroyed when the connection is terminated.

Step 11

Device# configure terminal

Enters global configuration mode.

Step 12

Disables logging on the virtual terminal.

Step 13

Exits to privileged EXEC mode.

Configuration Examples for L2TP Large-Scale Dial-Out per-User Attribute via AAA

This section provides the following configuration examples to show how to configure the L2TP Large-Scale Dial-Out per-User Attribute via AAA feature:

- LNS Configuration Example

- Per-User AAA Attributes Profile Example

- Virtual Access Interface Configuration Verification Example

- Virtual Access Interface Configuration Troubleshooting Example

LNS Configuration Example

The following partial example shows how to configure an LNS for the L2TP Large-Scale Dial-Out per-User Attribute via AAA feature:

!

vpdn enable

vpdn search-order domain

!

vpdn-group 1

.

.

.

request-dialout

protocol l2tp

rotary-group 1

virtual-template 1

initiate-to ip 10.0.1.194.2

local name lns

l2tp tunnel password 7094F3$!5^3

source-ip 10.0.194.53

!

Per-User AAA Attributes Profile Example

The following example shows the attribute-value pair (avpair) statements for a AAA profile to specify the per-user attributes:

5300-Router1-out Password = "cisco"

Service-Type = Outbound

cisco-avpair = "outbound:dial-number=5553021"

7200-Router1-1 Password = "cisco"

Service-Type = Outbound

cisco-avpair = "ip:route=10.17.17.1 255.255.255.255 Dialer1 100 name 5300-Router1"

5300-Router1 Password = "cisco"

Service-Type = Framed

Framed-Protocol = PPP

cisco-avpair = "lcp:interface-config=ip unnumbered loopback 0"

cisco-avpair = "ip:outacl#1=deny ip host 10.5.5.5 any log"

cisco-avpair = "ip:outacl#2=permit ip any any"

cisco-avpair = "ip:inacl#1=deny ip host 10.5.5.5 any log"

cisco-avpair = "ip:inacl#2=permit ip any any"

cisco-avpair = "multilink:min-links=2"

Framed-Route = "10.5.5.6/32 Ethernet4/0"

Framed-Route = "10.5.5.5/32 Ethernet4/0"

Idle-Timeout = 100

Virtual Access Interface Configuration Verification Example

The following example shows the virtual access interface configuration so you can check that the per-user AAA commands are correctly parsed:

Device# show interfaces virtual-access 3 configuration

Virtual-Access3 is an VPDN link (sub)interface

Derived configuration : 212 bytes

!

interface Virtual-Access3

ip vrf forwarding V1.25.com

ip unnumbered Loopback25

no peer default ip address

ppp authentication chap

end

Virtual Access Interface Configuration Troubleshooting Example

This section provides the following debugging session examples for a network configured with the L2TP Large-Scale Dial-Out per-User Attribute via AAA feature. Output is displayed for each command in the task.

Sample Output for the debug aaa per-user Command

Device# debug aaa per-user

%LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up

AAA/AUTHOR: Processing PerUser AV interface-config

AAA/AUTHOR: Processing PerUser AV route

AAA/AUTHOR: Processing PerUser AV route

AAA/AUTHOR: Processing PerUser AV outacl

AAA/AUTHOR: Processing PerUser AV outacl

AAA/AUTHOR: Processing PerUser AV inacl

AAA/AUTHOR: Processing PerUser AV inacl

Vi3 AAA/PERUSER/ROUTE: vrf name for vaccess: V1.25.com

Vi3 AAA/PERUSER/ROUTE: route string: IP route vrf V1.25.com 10.1.25.10 255.255.255.255 10.1.25.20 tag 120

Vi3 AAA/PERUSER/ROUTE: vrf name for vaccess: V1.25.com

Vi3 AAA/PERUSER/ROUTE: route string: IP route vrf V1.25.com 172.30.35.0 255.255.255.0 10.1.25.20 tag 120

AAA/PER-USER: mode = config; command = [ip access-list extended Virtual-Access3#41

permit icmp any any log

permit ip any any]

AAA/PER-USER: line = [ip access-list extended Virtual-Access3#41]

AAA/PER-USER: line = [permit icmp any any log]

AAA/PER-USER: line = [permit ip any any]

AAA/PER-USER: mode = config; command = [ip access-list extended Virtual-Access3#42

permit icmp any any log

permit ip any any]

AAA/PER-USER: line = [ip access-list extended Virtual-Access3#42]

AAA/PER-USER: line = [permit icmp any any log]

AAA/PER-USER: line = [permit ip any any]

AAA/PER-USER: mode = config; command = [IP route vrf V1.25.com 10.1.25.10 255.255.255.255 10.1.25.20 tag 120 IP route vrf V1.25.com 172.30.35.0 255.255.255.0 10.1.25.20 tag 120]

AAA/PER-USER: line = [IP route vrf V1.25.com 10.1.25.10 255.255.255.255 10.1.25.20 tag 120]

AAA/PER-USER: line = [IP route vrf V1.25.com 172.30.35.0 255.255.255.0 10.1.25.20 tag 120]

*Feb 28 07:35:19.616: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up

Sample Output for the debug vtemplate events and debug vtemplate cloning Commands

Device# debug vtemplate events

Device# debug vtemplate cloning

VT[Vi3]:Reuse interface, recycle queue size 1

VT[Vi3]:Set to default using 'encap ppp'

VT[Vi3]:Vaccess created

VT[Vi3]:Added new vtemplate cloneblk, now cloning from vtemplate

VT[Vi3]:Clone Vaccess from Virtual-Template25 (19 bytes)

VT[Vi3]:no ip address

VT[Vi3]:end

VT[Vi3]:Applying config commands on process "Dialer event" (25)

VT[Vi3]:no ip address

VT[Vi3]:end

%LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up

VT:Sending vaccess request, id 0x6401947C

VT:Processing vaccess requests, 1 outstanding

VT[Vi3]:Added new AAA cloneblk, now cloning from vtemplate/AAA

VT[Vi3]:Clone Vaccess from AAA (60 bytes)

VT[Vi3]:ip vrf forwarding V1.25.com

VT[Vi3]:ip unnumbered loopback25

VT[Vi3]:end

VT[Vi3]:Applying config commands on process "VTEMPLATE Background Mgr" (160)

VT[Vi3]:ip vrf forwarding V1.25.com

VT[Vi3]:ip unnumbered loopback25

VT[Vi3]:end

VT[Vi3]:MTUs ip 1500, sub 0, max 1500, default 1500

VT[Vi3]:Processing vaccess response, id 0x6401947C, result success (1)

VT[Vi3]:Added new AAA cloneblk, now cloning from vtemplate/AAA

VT[Vi3]:Clone Vaccess from AAA (82 bytes)

VT[Vi3]:IP access-group Virtual-Access3#51 in

VT[Vi3]:IP access-group Virtual-Access3#52 out

VT[Vi3]:end

VT[Vi3]:Applying config commands on process "PPP IP Route" (62)

VT[Vi3]:IP access-group Virtual-Access3#51 in

VT[Vi3]:IP access-group Virtual-Access3#52 out

VT[Vi3]:end

%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up

Additional References

For additional information related to L2TP large-scale dial-out per-user attributes using a AAA server, see to the following sections:

- Related Documents

- Standards

- MIBs

- RFCs

- Technical Assistance

Related Documents

Related Topic

Document Title

Large-scale dial-out

VPDN groups

Virtual interfaces

Per-user configuration

Descriptions of debug command output

Standards

Standards

Title

None

—

MIBs

MIBs

MIBs Link

None

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

If Cisco MIB Locator does not support the MIB information that you need, you can also obtain a list of supported MIBs and download MIBs from the Cisco MIBs page at the following URL:

To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:

RFCs

RFCs

Title

None

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

Command Reference

.

- virtual-template

x25 route 11111 interface Dialer0

x25 route 44444 interface Dialer0

!

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007–2009 Cisco Systems, Inc. All rights reserved.

Modem Script and System Script Support in Large-Scale Dial-Out

This feature module describes the Modem Script and System Script Support in Large-Scale Dial-Out feature and includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Configuration Tasks

- Monitoring and Maintaining Large-Scale Dial-Out Sessions

- Configuration Examples

- Command Reference

- Appendix

- Glossary

Feature Overview

Modem connection and system login chat scripts are often used when asynchronous dial-on-demand routing (DDR) is configured. Currently, however, the large-scale dial-out network architecture does not allow chat scripts for a particular session to be passed through the network. Cisco IOS Release 12.2(2)T allows modem and system chat scripts to pass through large-scale dial-out networks by allocating two new authentication, authorization, and accounting (AAA) attributes for outbound service.

The AAA attributes define specific AAA elements in a user profile. Large-scale dial-out supports Cisco attribute-value (AV) pairs and TACACS+ attributes. The Modem Script and System Script Support in Large-Scale Dial-Out feature provides two new outbound service attributes for passing chat scripts: modem-script and system-script.

Benefits

The Modem Script and System Script Support in Large-Scale Dial-Out feature allows users to use modem and system chat scripts by linking them to AAA service outbound attributes for use by Cisco network access servers in large-scale dial-out networks.

Related Documents

- Cisco IOS Dial Technologies Configuration Guide, Release 12.2

- Cisco IOS Security Configuration Guide , Release 12.2

- CiscoSecure ACS for Windows NT User Guide 2.0

Supported Platforms

The Asynchronous Line Monitoring feature feature was developed for and tested on several Cisco device platforms. Check Feature Navigator for the feature sets in which the Asynchronous Line Monitoring feature is available.

Determining Platform Support Through Cisco Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Cisco Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.

.

Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:

Supported Standards, MIBs, and RFCs

Standards

No new or modified standards are supported by this feature.

MIBs

No new or modified MIBs are supported by this feature.

.

RFCs

No new or modified RFCs are supported by this feature.

Configuration Tasks

See the following sections for configuration tasks for the Modem Script and System Script Support in Large-Scale Dial-Out feature. Each task in the list is identified as either optional or required.

- Creating the Dial-Out Profile (required)

- Creating the Chat Script (required)

- Verifying Modem and System Chat Scripts with Large-Scale Dial-Out (optional but recommended)

, Cisco IOS Release 12.2.

Creating the Dial-Out Profile

To specify a name for the modem script and, if needed, a system script using cisco-avpair attributes for outbound service, use the following syntax to enter these attributes in the dial-out profile:

cisco-avpair = "outbound:modem-script=script-name"

cisco-avpair = "outbound:system-script=script-name"

To specify a name for the modem script and, if needed, a system script using TACACS+ attributes for outbound service, use the following syntax to enter these attributes in the dial-out profile:

service = outbound {

modem-script = script-name

system-script = script-name

}

Timesaver Remember that the dial-out profile name must have the characters “-out” appended to it and that the only required attribute for a profile is the Cisco AV pair outbound:dial-number.

See the section “Dial-Out Profile Examples” for examples of dial-out profiles.

Creating the Chat Script

To configure the modem or system script name in the Cisco network access server (NAS), use the following command in global configuration mode:

Command

Purpose

Provides commands to dial a modem and commands to log on to remote systems when using DDR.

See the section “Chat Script Example” for an example of a chat script that works with a dial-out-profile.

Verifying Modem and System Chat Scripts with Large-Scale Dial-Out

command. See the “Verification Example” for a sample of the output from this command.

Monitoring and Maintaining Large-Scale Dial-Out Sessions

To monitor and maintain large-scale dial-out sessions, use the following commands in EXEC mode as needed:

Command

Purpose

Removes all dialer sessions and disconnects links.

Displays configuration information and information about AAA/TACACS+ authorization.

Displays all dialer sessions.

Configuration Examples

This section provides the following configuration examples:

- Dial-Out Profile Examples

- Chat Script Example

- Verification Example

Dial-Out Profile Examples

The following is an example of a Cisco AV pair dial-out profile named “evergreen” that defines a modem script named “dialer-script”:

evergreen-out Password = "cisco",

User-Service-Type = Outbound-User

cisco-avpair = "outbound:dial-number=5551212",

cisco-avpair = "outbound:addr=5.1.1.1",

cisco-avpair = "outbound:send-secret=cisco",

cisco-avpair = "outbound:modem-script=dialer-script"

The following is an example of how to define the same profile for TACACS+:

user = evergreen-out

{

service = outbound {

dial-number = 5551212

addr = 5.1.1.1

send-secret = cisco

modem-script = dialer-script

}

service = ppp protocol = ip {

default attribute = permit

}

}

Chat Script Example

The following example creates a chat script for the Cisco NAS that references the dialer-script modem script created in the dial-out profile:

chat-script dialer-script "" AT OK ATDT\T TIMEOUT 60 CONNECT

Verification Example

privileged EXEC command:

00:01:07: %LSDialout: temporary debug to verify the data integrity

00:01:07: dial number = 5551212

00:01:07: dialnum_count = 1

00:01:07: force_56 = 0

00:01:07: routing = 0

00:01:07: data_svc = -1

00:01:07: port_type = -1

00:01:07: map_class =

00:01:07: modem_script = dialer-script

00:01:07: system_script =

00:01:07: ip_address = 5.1.1.1

00:01:07: send_secret = cisco

00:01:07: send_auth = -1

00:01:07: send_name =

00:01:07: class =

Command Reference

.

Appendix

The following new Cisco AV pairs and TACACS+ attributes are added to the large-scale dial outbound service attributes:

Modem Script Attribute

Specifies a name for the modem script.

Cisco AV Pair:

cisco-avpair = "outbound:modem-script=VALUE"

TACACS+ Support:

service = outbound {

modem-script = VALUE

}

Value:

Modem script name that you assign.

System Script Attribute

Specifies a name for the system script.

Cisco AV Pair:

cisco-avpair = "outbound:system-script=VALUE"

TACACS+ Support:

service = outbound {

system-script = VALUE

}

Value:

System script name that you assign.

Glossary

—authentication, authorization, and accounting. Suite of network security services that provide the primary framework through which access control can be set up on your Cisco router or access server.

—Data items sent between a network access server and a daemon that are used to direct AAA activities.

—See AAA.

—Strings of text used to send commands for modem dialing, logging in to remote systems, and initializing asynchronous devices connected to an asynchronous line.

—Attributes that define specific AAA elements in a user profile. Large-scale dial-out supports a subset of Ascend AV pairs, RADIUS attributes, and a map class attribute providing outbound dialing services.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

© 2005–2009 Cisco Systems, Inc. All rights reserved.

Large-Scale Dial-Out (LSDO) VRF Aware

Feature History

Release

Modification

12.2(8)T

This feature was introduced.

This document describes the LSDO VRF Aware feature in Cisco IOS Release 12.2(8)T and includes the following sections:

- Feature Overview

- Supported Platforms

- Supported Standards, MIBs, and RFCs

- Prerequisites

- Configuration Tasks

- Configuration Examples

- Command Reference

- Glossary

Feature Overview

Currently, the Cisco large-scale dial-out (LSDO) feature is not supported in a Multiprotocol Label Switching (MPLS) virtual private network (VPN), which means it does not support tunneling protocols and cannot take advantage of cost benefits inherent in an MPLS VPN. (See the sections “Benefits” and the “Related Documents” for more details on the benefits of MPLS VPN.) Beginning with Cisco IOS Release 12.2(8)T, large-scale dial-out will support the Layer 2 Tunnel Protocol (L2TP) in an MPLS VPN.

The basic operation of large-scale dial-out relies on per-user static routes stored in an authentication, authorization, and accounting (AAA) server, and redistributed static and redistributed connected routes to put better routes pointing to the same remote network or host on the alternate network access server (NAS).

A static route is manually configured on a NAS. If the static route that pointed to the next hop of the NAS has a name, that name with the -out suffix attached becomes the profile name.

When a packet arrives on a dialer interface where a static map is not configured, the dial string is retrieved from the AAA server. The query made to the AAA server is based on the destination IP address of the packet received.

When using L2TP VPN large-scale dial-out, overlapping IP addresses are often present in virtual routing and forwarding instances (VRFs), so that a unique key is needed to retrieve the correct route from the AAA server. With VPDN as a dial-out resource, a virtual access interface is created for maintaining each PPP session. Software prior to Cisco IOS Release 12.2(8)T did not update the VRF information on the virtual access interface; rather, this information was cloned from the dialer interface.

In the Cisco IOS Release 12.2(8)T software, the VRF table identifier is retrieved from the incoming packet and is mapped to the VRF name. This VRF name and the destination IP address are combined to make the unique key needed to retrieve the dial string and other user profile information from the AAA server. When response from the AAA server is received and the virtual access interface is created, the virtual access interface is updated with VRF information that was retrieved from the incoming packet. As with profile names on dialer interfaces, the IP address and VRF name combination with the -out suffix attached becomes the profile name for large-scale dial-out in MPLS VPN using L2TP.

Note Another way to build a unique key is to use the name of the IP route. In this situation, the key is made from the IP route name and VRF name combination with the -out suffix attached. Refer to the technical note listed in the “Related Documents” section for more information.

Benefits

Layer 2 Tunneling Technologies Trim Costs by Forwarding Calls over the Internet

Access VPNs use Layer 2 tunneling technologies to create a virtual point-to-point connection between users and the customer network. These tunneling technologies provide the same direct connectivity as the expensive Public Switched Telephone Network (PSTN) by using the Internet. Instead of connecting directly to the network by using the PSTN, access VPN users need only use the PSTN to connect to the Internet service provider (ISP) local point of presence (POP). The ISP then uses the Internet to forward users from the POP to the customer network. Forwarding a user call over the Internet provides cost savings for the customer.

The MPLS VPN Model Simplifies Network Routing Configuration

The MPLS VPN model simplifies network routing by allowing VPN services to be supported in service provider networks. An MPLS VPN user can generally employ the backbone of the service provider as the default route in communicating with all of the other VPN sites.

The customer outsources the responsibility for the information technology (IT) infrastructure to an ISP that maintains the pool of modems the remote users dial in to, the access servers, and the internetworking expertise. The customer is responsible only for authenticating its users and maintaining its network.

L2TP Large-Scale Dial-Out Benefits from MPLS VPN Environment

The unique key created from the VRF name and the destination IP address allows retrieval of the dial string and other user profile information from a AAA server using L2TP in an MPLS VPN environment.

Restrictions

the dialer string that large-scale dial-out needs to construct the dynamic dialer map. This feature cannot create virtual access interfaces in the large-scale dial-out environment.

Related Documents

Additional information about configuring networks that can take advantage of this feature can be found in the following Cisco IOS documentation:

- Cisco IOS Dial Technologies Command Reference , Release 12.2.

- Cisco IOS Dial Technologies Configuration Guide , Release 12.2. Refer to the chapter “Configuring Large-Scale Dial-Out” in the part “Dial Access Specialized Features,” and the chapter “Configuring Virtual Private Networks” in the part “Virtual Templates, Profiles, and Networks.”

- Cisco IOS Switching Services Command Reference , Release 12.2.

- Cisco IOS Switching Services Configuration Guide , Release 12.2. Refer to the chapter “Multiprotocol Label Switching Overview” in the part “Multiprotocol Label Switching.”

Supported Platforms

Use Cisco’s Feature Navigator tool to determine which platforms support the Asynchronous Line Monitoring feature feature.

Determining Platform Support Through Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Feature Navigator. Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image.

.

Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Feature Navigator home page at the following URL:

Supported Standards, MIBs, and RFCs

Standards

None

MIBs

None

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

RFCs

None

Prerequisites

No new Cisco IOS commands are introduced with the Asynchronous Line Monitoring feature feature. Before configuring this feature, read through the chapters listed in the “Related Documents” section, to be sure you know how to configure VPDNs, dialer interfaces, and MPLS, then use the examples in the section “Configuration Examples” to help you determine the configuration you need for your network.

Configuration Tasks

No new configuration tasks are required for configuring the Asynchronous Line Monitoring feature feature. See the sections “Prerequisites” and “Related Documents” for more information.

Monitoring and Maintaining Asynchronous Line Monitoring feature

Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.

To monitor and maintain Asynchronous Line Monitoring feature feature, use the following EXEC commands:

Command

Purpose

Displays general diagnostic information for interfaces configured for DDR.

Displays the routing protocol information associated with a VRF.

Displays the IP routing table associated with a VPN routing and VRF forwarding instance.

Displays the set of defined VRF instances and associated interfaces.

Displays information about active L2F protocol tunnel and L2F message identifiers in a VPDN.

Displays all VPDN domains and DNIS groups configured on the NAS.

Displays a summary of the relationships among VPDN groups and customer or VPDN profiles, and summarizes the configuration of a VPDN group including domain or DNIS, loadsharing information, and current session information.

Displays the content of the failure history table.

Displays the multilink sessions authorized for all VPDN groups.

Displays information about active L2TP or L2F sessions in a VPDN.

Displays information about active L2TP or L2F tunnels in a VPDN.

Configuration Examples

This section contains partial sample configurations of the Asynchronous Line Monitoring feature feature. (Additional examples can be found in the technical note listed in the “Related Documents” section.)

In the following examples, VRF VPN_A has two hosts with the IP address 1.1.1.1 and 2.2.2.2 and, similarly, VRF VPN_B has two hosts with IP address 1.1.1.1 and 2.2.2.2. The AAA server is configured with a list containing “10.10.10.10-VPN_A-out” and “10.10.10.10-VPN_B-out” as keys to search on.

Note The network addresses used in the following configuration are examples only and will not work if tried in an actual network configuration.

LNS Configuration

This partial example configures L2TP dial-out tunnels to an L2TP access concentrator (LAC) from an L2TP network server (LNS):

request-dialout

protocol l2tp

rotary-group 1

! LAC IP address:

initiate-to ip 172.16.0.2

local name PE2_LNS

l2tp tunnel password 7 13!9@61&

Dialer Configuration

This partial example configures the dialer interface:

interface Dialer 1

! Global IP address:

ip address 10.10.10.10

encapsulation ppp

dialer in-band

dialer aaa

dialer vpdn

dialer-group 1

ppp authentication chap

Routing Configuration

This partial example configures the VRF static routes:

ip route vrf VPN_A 1.1.1.1 255.255.255.255 Dialer1

ip route vrf VPN_A 2.2.2.2 255.255.255.255 Dialer1

ip route vrf VPN_B 1.1.1.1 255.255.255.255 Dialer1

ip route vrf VPN_B 2.2.2.2 255.255.255.255 Dialer1

Command Reference

.

Glossary

—Layer 2 Tunnel Protocol. A tunneling protocol that permits separating the remote access network function—terminating the PSTN circuit, for example—from the local network access operations such as authenticating and authorizing the remote user.

—See LAC.

—See LNS.

—L2TP access concentrator. A node that acts as one side of an L2TP tunnel endpoint and is a peer to the LNS. The LAC sits between an LNS and a remote system and forwards packets to and from each. Packets sent from the LAC to the LNS require tunneling with the L2TP protocol. The connection from the LAC to the remote system is either local or a PPP link.

—See L2TP.

—L2TP network server. A device that terminates an L2TP tunnel. It receives the remote user PPP connection over an L2TP tunnel. The LNS authenticates and authorizes the remote user and then forwards packets between the remote user and the data network.

—Multiprotocol Label Switching. Switching method that forwards IP traffic using a label. This label instructs the routers and the switches in the network where to forward the packets based on pre-established IP routing information.

—See MPLS.

—network access server. A device that provides local network access to users across a remote access network such as the PSTN. For example, a NAS may provide access to a user dialing in from the PSTN to the data network, that is, it terminates the PSTN circuit, terminates the remote user PPP session, authenticates and authorizes the remote user, and finally forwards packets between the remote user and the data network.

—See NAS.

—See VPDN.

—See VRF.

—virtual private dialup network. A type of access VPN that uses PPP to interface with the subscriber. VPDN enables the service provider to configure VPNs across an IP access network that connects to the VRFs on a PE. VPDN uses the Layer 2 Tunnel Protocol (L2TP) to extend or "tunnel" a PPP session across the IP access network.

—virtual routing and forwarding instance. Identifies a separate VPN within a particular MPLS VPN network domain.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007-2008 Cisco Systems, Inc. All rights reserved.

Peer Pool Backup

The Asynchronous Line Monitoring feature feature provides control over selection of IP address pools in large-scale dial-out networks where authentication, authorization, and accounting (AAA) servers and network access servers (NASs) are controlled by different groups. This feature allows you to define alternate sources for IP address pools in the event the original address pool is not present or is exhausted.

Feature History for the Asynchronous Line Monitoring feature Feature

Release

Modification

12.2(8)B

This feature was introduced.

12.3(4)T

This feature was integrated into Cisco IOS Release 12.3(4)T.

Finding Support Information for Platforms and Cisco IOS Software Images

at the login dialog box and follow the instructions that appear.

Contents

- Prerequisites for Peer Pool Backup

- Information About Peer Pool Backup

- How to Configure Peer Pool Backup

- Configuration Examples for Peer Pool Backup

- Additional References

- Command Reference

Prerequisites for Peer Pool Backup

interface configuration commands introduced with the Asynchronous Line Monitoring feature feature work with IP address pools. Before beginning the configuration tasks, see the “Related Documents” section for information about IP address pooling configuration tasks.

Information About Peer Pool Backup

To configure Peer Pool Backup, you need to understand the following concepts:

- Alternate Sources for IP Address Pools

- Backup Pools to Prevent Local Pool Exhaustion

- Limit Loading of Dynamic Pools

- Peer Pool Backup Feature Interface Compatibility

Alternate Sources for IP Address Pools

The Asynchronous Line Monitoring feature feature is useful in large-scale dial-out environments with large numbers of independently controlled AAA servers that can make it difficult for the NAS to provide proper IP address pool resolution in the following cases:

- A new pool name is introduced by one of the AAA servers before that pool is set up on the NAS.

- An existing local pool becomes exhausted, but the owner of that AAA server has other pools that would be acceptable as an IP address source.

, which allow you to define alternate sources for IP address pools in the event the original address pool is not present or is exhausted.

Backup Pools to Prevent Local Pool Exhaustion

interface configuration command to supplement the pool names supplied by AAA.

Limit Loading of Dynamic Pools

command to control attempts to load all dynamic pools when the AAA-supplied pool name is not an existing local pool name.

Peer Pool Backup Feature Interface Compatibility

The Asynchronous Line Monitoring feature feature has been successfully tested at Cisco Systems in networks using ISDN, asynchronous, and digital subscriber line (DSL) interfaces.

How to Configure Peer Pool Backup

The following sections describe how to configure the Asynchronous Line Monitoring feature feature. Each task is identified as required or optional.

- Configuring IP Pools (required)

- Suppressing Dynamic Pool Load Attempts (required)

- Verifying Asynchronous Line Monitoring feature (optional)

Configuring IP Pools

interface configuration command, to supplement the pool names supplied by AAA.

SUMMARY STEPS

]

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# interface serial 1:23

Specifies the interface and enters interface configuration mode.

Step 4

peer pool backup

interface configuration command to supplement the pool names supplied by AAA.

Step 5

peer default ip address pool pool3 pool4 pool5

Specifies a list of pools for the interface to use, in search order.

Step 6

exit

Exits interface configuration mode and returns to global configuration mode.

Step 7

]

Router(config)# ip local pool pool3 10.4.4.2

Creates one or more local IP address pools.

Step 8

exit

Exits configuration mode.

This task configures basic IP address pooling and pool backup. See the “Configuration Examples for Peer Pool Backup” section for additional configuration information.

Suppressing Dynamic Pool Load Attempts

Perform the following task to suppress an attempt to load all dynamic pools from the AAA server.

SUMMARY STEPS

DETAILED STEPS

Command or Action

Purpose

Step 1

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

interface Virtual-Template 1

Specifies the interface and enters interface configuration mode.

Step 4

peer pool static

Suppresses an attempt to load all dynamic pools from the AAA server.

Step 5

exit

Exits interface configuration mode.

See the “Configuration Examples for Peer Pool Backup” section for additional configuration information.

Verifying Asynchronous Line Monitoring feature

command is configured, or if the pools were refreshed within the last two minutes.

SUMMARY STEPS

DETAILED STEPS

Use this command to enter privileged EXEC mode. Enter your password if prompted.

text.

Router# debug ip peer

*Jan1 02:11:10.455: Se0:22 AAA/AUTHOR/IPCP: Start.Her address 0.0.0.0, we want 0.0.0.0

*Jan1 02:11:10.455: Se0:22 AAA/AUTHOR/IPCP: Says use pool poolA

*Jan1 02:11:10.459: Se0:22: IPPOOL: using pool poolA

*Jan1 02:11:10.459: Se0:22: Use AAA pools: poolA

< AAA-supplied pool name. >

*Jan1 02:11:10.459: Se0:22: Backup pools : back1 back2

< Determines pool names to use if address is not obtained from AAA pool name. >

< Only seen when the peer pool backup command is configured. >

< Pool name from peer default ip address pool back1 back2 command. >

*Jan1 02:11:10.459: Se0:22: Pools to search : poolA back1 back2

< Pools searched in the above order, AAA-supplied name first. >

*Jan1 02:11:10.459: Se0:22 AAA/AUTHOR/CONFIG: Pools refreshed for pool poolA

< Since pool poolA is missing, an attempt is made to load it as a >

< dynamic pool from AAA >

*Jan1 02:11:10.459: AAA/AUTHOR (0x5): Pick method list 'default'

.

.

.

*Jan1 02:11:10.475: Se0:22 AAA/AUTHOR/CONFIG: Set pool timeout to 2 mins

*Jan1 02:11:10.475: Se0:22 AAA/AUTHOR/CONFIG: Pool back1 refresh skipped

< Another dynamic pool load attempt was suppressed for pool "back1," which

< is also missing since software just loaded all dynamic pools when

< looking for pool poolA. >

*Jan1 02:11:10.475: Se0:22 AAA/AUTHOR/CONFIG: Pools refreshed 0 seconds ago

< Software tries to refresh the dynamic pools from AAA if 2 minutes have elapsed. >

*Jan1 02:11:10.475: Se0:22 AAA/AUTHOR/CONFIG: Pools will timeout in 2 mins

< The above message is due to the presence of some dynamic pools on AAA where

< these dynamic pools have a life time of 2 minutes; unrelated to the

< pools we are focusing on, but loaded in response to the dynamic load. >

*Jan1 02:11:10.475: Se0:22: Pool back2 returned address = 10.2.2.2

.

.

.

*Jan1 02:18:19.063: Se0:22 AAA/AUTHOR/IPCP: Says use pool poolA

*Jan1 02:18:19.063: Se0:22: IPPOOL: using pool poolA

*Jan1 02:18:19.067: Se0:22: AAA pools to match: poolA

*Jan1 02:18:19.067: Se0:22: Configured pools: back1 back2 poolA

*Jan1 02:18:19.067: Se0:22: Matched AAA pools : poolA

*Jan1 02:18:19.067: Se0:22: Use AAA pools: poolA

*Jan1 02:18:19.067: Se0:22: Backup pools : back1 back2 poolA

*Jan1 02:18:19.067: Se0:22: Pools to search : poolA back1 back2

*Jan1 02:18:19.067: Se0:22: Dynamic IP pool loading suppressed: poolA

< No attempt is made to dynamically load pools, even if the pool >

< being processed ("poolA") is not present. This is due to the >

< peer pool static command; otherwise software would try to load >

< dynamic pools if they have not been load in the last 2 minutes. >

*Jan1 02:18:19.067: Se0:22: Dynamic IP pool loading suppressed: back1

*Jan1 02:18:19.067: Se0:22: Dynamic IP pool loading suppressed: back2

*Jan1 02:18:19.067: Se0:22: Pool back2 returned address = 10.2.2.2

Verifying That a Pool Was Not Skipped

text.

*Jan1 02:40:44.507: Se0:22 AAA/AUTHOR/IPCP: Says use pool poolA

*Jan1 02:40:44.507: Se0:22: IPPOOL: using pool poolA

*Jan1 02:40:44.507: Se0:22: Use AAA pools: poolA

*Jan1 02:40:44.507: Se0:22: Backup pools : back1 back2

*Jan1 02:40:44.511: Se0:22: Pools to search : poolA back1 back2

*Jan1 02:40:44.511: Se0:22 AAA/AUTHOR/CONFIG: Pool poolA refresh skipped

*Jan1 02:40:44.511: Se0:22 AAA/AUTHOR/CONFIG: Pools refreshed 84 seconds ago

< The peer pool static command was not configured, but software has already >

< refreshed dynamic pools from AAA in the last 2 minutes. >

*Jan1 02:40:44.511: Se0:22 AAA/AUTHOR/CONFIG: Pool back1 refresh skipped

*Jan1 02:40:44.511: Se0:22 AAA/AUTHOR/CONFIG: Pools refreshed 84 seconds ago

*Jan1 02:40:44.511: Se0:22 AAA/AUTHOR/CONFIG: Pools will timeout in 0 mins

*Jan1 02:40:44.511: Se0:22: Pool back2 returned address = 10.2.2.2

Monitoring and Maintaining Asynchronous Line Monitoring feature

EXEC command.

Configuration Examples for Peer Pool Backup

This section provides the following configuration examples:

- ISDN Pool Backup Configuration: Example

- DSL Static Pool Backup Configuration: Example

- Pool Backup with Local Restrictions Configuration: Example

ISDN Pool Backup Configuration: Example

command are searched by the pool software in the event the original address pool is not present:

aaa new-model

aaa authentication ppp default group radius

aaa authorization exec default group radius

aaa authorization network default group radius

!

ip routing

isdn switch-type primary-5ess

!

controller t1 1

framing esf

clock source line primary

linecode b8zs

pri-group timeslots 1-24

!

interface serial 1:23

ip address 10.4.4.1 255.255.255.0

encapsulation ppp

ppp authentication chap

dialer-group 1

peer pool backup

peer default ip address pool pool3 pool4 pool5

isdn switch-type primary-5ess

.

.

.

dialer-list 1 protocol ip permit

ip local pool pool2 10.4.4.2

ip local pool pool3 10.4.4.3

ip local pool pool4 10.4.4.4

ip local pool pool5 10.4.4.5

DSL Static Pool Backup Configuration: Example

command prevents any attempt by the AAA server to load a dynamic IP address pool:

aaa new-model

aaa authentication ppp default group radius

aaa authorization exec default group radius

aaa authorization network default group radius

!

interface ATM0/0/0

no ip address

no ip directed-broadcast

no ip route-cache

no atm ilmi-keepalive

!

interface ATM0/0/0.2 point-to-point

pvc 8/36

encapsulation aal5snap

protocol pppoe

!

interface Ethernet0/0/1

ip address 10.1.1.8 255.255.255.0

no ip directed-broadcast

!

interface Virtual-Template 1

ip address 10.4.4.1 255.255.255.0

encapsulation ppp

ppp authentication chap

no ip directed-broadcast

peer pool static

peer default ip address pool pool3 pool4 pool5

!

ip classless

radius-server host 172.30.166.121

radius-server key lab

radius-server vsa send accounting

radius-server vsa send authentication

!

ip local pool pool2 10.4.4.2

ip local pool pool3 10.4.4.3

ip local pool pool4 10.4.4.4

ip local pool pool5 10.4.4.5

Pool Backup with Local Restrictions Configuration: Example

command.

command; only the pools named pool1 and pool2 will be searched.

interface serial 1:23

ip address 10.4.4.1 255.255.255.0

encapsulation ppp

ppp authentication chap

dialer-group 1

peer pool backup

peer match aaa-pools

peer default ip address pool pool1 pool2

isdn switch-type primary-5ess

command list, so that now poolA will be used by the pool software and the search order will be poolA, pool1, and then pool2. The pool named poolA is used first because AAA-supplied data is always given precedence over local data.

interface serial 1:23

ip address 10.4.4.1 255.255.255.0

encapsulation ppp

ppp authentication chap

dialer-group 1

peer pool backup

peer match aaa-pools

peer default ip address pool poolA pool1 pool2

isdn switch-type primary-5ess

text to indicate commands involved in the reports.):

*Jan1 02:08:23.919: Se0:22 AAA/AUTHOR/IPCP: Says use pool poolA

*Jan1 02:08:23.919: Se0:22: IPPOOL: using pool poolA

*Jan1 02:08:23.919: Se0:22: AAA pools to match: poolA

*Jan1 02:08:23.919: Se0:22: Configured pools: pool1 pool2

*Jan1 02:08:23.919: Se0:22: Matched AAA pools :

< The peer match aaa-pools command was specified, but pool named poolA was>

< not in the configured pool list, so the pool name provided by AAA is discarded >

*Jan1 02:08:23.919: Se0:22: Use AAA pools:

*Jan1 02:08:23.919: Se0:22: Backup pools : pool1 pool2

*Jan1 02:08:23.919: Se0:22: Pools to search : pool1 pool2

*Jan1 02:08:23.919: Se0:22 AAA/AUTHOR/CONFIG: Pools refreshed for pool pool1

*Jan1 02:08:23.919: Se0:22 AAA/AUTHOR/CONFIG: Pools refreshed for pool pool1

*Jan1 02:08:23.919: AAA/AUTHOR (0x3): Pick method list 'default'

.

.

.

*Jan1 02:08:23.967: Se0:22 AAA/AUTHOR/CONFIG: Set pool timeout to 2 mins

*Jan1 02:08:23.967: Se0:22 AAA/AUTHOR/CONFIG: Pools will timeout in 2 mins

*Jan1 02:08:23.967: Se0:22: Pool pool2 returned address = 10.2.2.2

*Jan1 02:08:23.967: Se0:22 AAA/AUTHOR/IPCP: Pool returned 10.2.2.2

Additional References

The following sections provide references related to the Asynchronous Line Monitoring feature feature.

Related Documents

Related Topics

Document Title

IP address pooling

” in the chapter “Configuring Media-Independent PPP and Multilink PPP”

Standards

Standards

Title

None

—

MIBs

MIBs

MIBs Link

None

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

RFCs

RFCs

Title

None

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

Command Reference

.

- peer pool backup

- peer pool static

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007–2009 Cisco Systems, Inc. All rights reserved.

Dial Networking Business Applications

This chapter provides an introduction to common dial networking scenarios used by service providers and enterprises and includes the following sections:

- Dial Networking for Service Providers and Enterprises

- Common Dial Applications

- IP Address Strategies

Providing dial access means to set up one or more access servers or routers to allow on-demand connectivity for individual remote nodes or remote offices. The dial network solutions described in this chapter are based on business case scenarios. Depending on your business application, dial access has different implementations.

Dial Networking for Service Providers and Enterprises

Service providers tend to supply public and private dial-in services for businesses or individual home users. Enterprises tend to provide private dial-in access for employees dialing in from remote LANs (such as a remote office) or individual remote nodes (such as a telecommuter). Additionally, there are hybrid forms of dial access—virtual private dialup networks (VPDNs)—that are jointly owned, operated, and set up by both service providers and enterprises.

Figure 1 displays a common dial topology used by an Internet service provider (ISP). The central dial-in site is owned and controlled by the ISP, who only accepts dial-in calls. Enterprises and individual remote clients have no administrative control over the point of presence (POP) of the ISP.

Note Many additional dial network strategies exist for different business applications. This overview is intended to provide only a sample of the most common dial business needs as experienced by the Cisco dial escalation team.

Figure 1 Sample Dial Network for an ISP

Enterprises can provide bidirectional access services with remote LANs and one-way dial-in access for standalone remote nodes. Bidirectional access means that remote LANs can dial in to the enterprise, and the enterprise can dial out to the remote LANs. A remote LAN can be a large remote office or a small home office. A standalone remote node can be an individual PC that is dynamically assigned an IP address from the modem pool of the enterprise. In most cases, an enterprise has complete administrative control over its local and remote devices. (See Figure 2.)

Figure 2 Sample Dial Network for an Enterprise

Service providers and enterprises both benefit from a hybrid dial solution called VPDN. Service providers offer virtually private access to enterprises by providing the dial-in access devices for the enterprise to use (for example, access servers and modem pools). In this solution, service providers construct the networking fabric for city-to-city dial connectivity for the enterprise. Enterprises provide only a home gateway router (with no attached modems) and a WAN connection to their service provider. VPDN dial solutions enable the enterprise to continue to maintain complete administrative control over its remote locations and network resource privileges. (See Figure 3.)

Figure 3 Sample VPDN for Service Providers and Enterprises

Common Dial Applications

The hardware and software configuration designs for dial networks are derived from business operations needs. This section describes several of the most common business dial scenarios that Cisco Systems is supporting for basic IP and security services.

Refer to the scenario that best describes your business or networking needs:

- The following dial scenarios are commonly used by service providers. For detailed description and configuration information, see the chapter “Telco and ISP Dial Scenarios and Configurations” later in this manual.

(on–or two access servers at the central dial-in site)

(m–e than two access servers at the central dial-in site, Multichassis Multilink PPP or MMP)

- The following dial scenarios are commonly used by enterprises. For detailed description and configuration information, see the chapter “ Enterprise Dial Scenarios and Configurations .”

IP Address Strategies

Exponential growth in the remote access router market has created new addressing challenges for ISPs and enterprise users. Companies that use dial technologies seek addressing solutions that will:

- Minimize Internet access costs for remote offices

- Minimize configuration requirements on remote access routers

- Enable transparent and dynamic IP address allocation for hosts in remote environments

- Improve network security capabilities at each remote small office, home office site

- Conserve registered IP addresses

- Maximize IP address manageability

Remote networks have variable numbers of end systems that need access to the Internet; therefore, some ISPs are interested in allocating just one IP address to each remote LAN.

In enterprise networks where telecommuter populations are increasing in number, network administrators need solutions that ease configuration and management of remote routers and provide conservation and dynamic allocation of IP addresses within their networks. These solutions are especially important when network administrators implement large dial-up user pools where ISDN plays a major role.

Choosing an Addressing Scheme

Use an IP addressing scheme that is appropriate for your business scenario as described in the following sections:

- Classic IP Addressing

- Cisco Easy IP

Additionally, here are some addressing issues to keep in mind while you evaluate different IP address strategies:

- How many IP addresses do you need?

- Do you want remote clients to dial in to your network and connect to server-based services, which require statically assigned IP addresses?

- Is your primary goal to provide Internet services to a network (for example, surfing the web, downloading e-mail, using TCP/IP applications)?

- Can you conduct business with only a few registered IP addresses?

- Do you need a single contiguous address space, or can you function with two non-contiguous address spaces?

Classic IP Addressing

This section describes two classic IP addressing strategies that you can use to set up dial-in access. Classic IP addresses are statically or dynamically assigned from your network to each site router or dial-in client. The IP address strategy you use depends on whether you are allowing remote LANs or individual remote clients to dial in.

A remote LAN usually consists of a single router at the gateway followed by multiple nodes such as 50 PCs. The IP address on the gateway router is fixed or statically assigned (for example, 3.3.3.3). This device always uses the address 3.3.3.3 to dial in to the enterprise or service provider network. There is also a segment or subnet associated with the gateway router (for example, 2.1.1.0 255.255.255.0), which is defined by the dial-in security server.

For individual remote clients dialing in, a specific range or pool of IP addresses is defined by the gateway access server and dynamically assigned to each node. When a remote node dials in, it receives an address from the specified address pool. This pool of addresses usually resides locally on the network access server. Whereas, the remote LANs have predefined or statically assigned addresses. The accompanying subnet is usually statically assigned too. (See Figure 4.)

Figure 4 Classic IP Address Allocation

Here are some advantages and disadvantages of manually assigning IP addresses:

- Advantages

– Web servers or Xservers can be stationed at remote locations.

– Since addresses are members of your network, they are perfectly transparent.

- Disadvantages

– IP address assignments can be difficult to administer or manage. You may also need to use complicated subnetting configurations.

– Statically assigned IP addresses use up precious address space.

– Strong routing configuration skills are usually required.

Cisco Easy IP

Two of the key problems facing the Internet are depletion of IP address space and scaling in routing. The Cisco Easy IP feature combines Network Address Translation (NAT) and PPP/Internet Protocol Control Protocol (IPCP). This feature enables a Cisco router to automatically negotiate its own registered WAN interface IP address from a central server and allows all remote hosts to access the global Internet using this single registered IP address. Because Cisco Easy IP uses existing port-level multiplexed NAT functionality within the Cisco IOS software, IP addresses on the remote LAN are invisible to the Internet.

Cisco Easy IP Component Technologies

Cisco Easy IP solution is a scalable, standards-based, “plug-and-play” solution that comprises a combination of the following technologies:

- NAT—Described in RFC 1631. NAT operates on a router that usually connects two or more networks together. Using Cisco Easy IP, at least one of these networks (designated as “inside” or “LAN”) is addressed with private (RFC 1918) addresses that must be converted into a registered address before packets are forwarded onto the other registered network (designated as “outside” or “WAN”). Cisco IOS software provides the ability to define one-to-one translations (NAT) as well as many-to-one translations (Port Address Translation [PAT]). Within the context of Cisco Easy IP, PAT is used to translate all internal private addresses to a single outside registered IP address.

- PPP/IPCP—Defined in RFC 1332. This protocol enables users to dynamically configure IP addresses over PPP. A Cisco Easy IP router uses PPP/IPCP to dynamically negotiate its own WAN interface address from a central access server or DHCP server.

Figure 5 shows an example of how Cisco Easy IP works. A range of registered or unregistered IP addresses are used inside a company’s network. When a dial-up connection is initiated by an internal node, the router uses the Cisco Easy IP feature to rewrite the IP header belonging to each packet and translate the private address into the dynamically assigned and registered IP address, which could be borrowed from a service provider.

Figure 5 Translating and Borrowing IP Addresses

For a more detailed description of how Cisco Easy IP works, see the chapter “Configuring Cisco Easy IP.”

Key Benefits of Using Cisco Easy IP

The Cisco Easy IP feature provides the following benefits:

- Reduces Internet access costs by using dynamically allocated IP addresses. Using dynamic IP address negotiation (PPP/IPCP) at each remote site substantially reduces Internet access costs. Static IP addresses cost more to purchase compared to dynamically allocated or rented IP addresses. Cisco Easy IP enables you to rent IP addresses. In addition, dynamically assigned IP addresses saves you time and money associated with subnet mask configuration tasks on hosts. It also eliminates the need to configure host IP addresses when moving from network to network.

- Simplifies IP address management. Cisco Easy IP enables ISPs to allocate a single registered IP address to each remote LAN. Because only a single registered IP address is required to provide global Internet access to all users on an entire remote LAN, customers and ISPs can use their registered IP addresses more efficiently.

- Conserves registered IP addresses. Suppose you want to connect to the Internet, but not all your hosts have globally unique IP addresses. NAT enables private IP internetworks that use nonregistered or overlapping IP addresses to connect to the Internet. NAT is configured on the router at the border of a stub domain (referred to as the inside network ) and a public network such as the Internet (referred to as the outside network ). The private addresses you set up on the inside of your network translate in to a single registered IP addresses on the outside of your network.

- Provides remote LAN IP address privacy. Because Cisco Easy IP uses existing port-level multiplexed NAT functionality within Cisco IOS software, IP addresses on the remote LAN are invisible to the Internet, making the LAN inherently more secure. As seen by the external network, the source IP address of all traffic from the remote LAN is the single registered IP address of the WAN interface for the Cisco Easy IP router.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

© 2001–-2009 Cisco Systems, Inc. All rights reserved.

Enterprise Dial Scenarios and Configurations

This chapter provides sample configurations for specific dial scenarios used by enterprise networks (not telephone companies or Internet service providers). Each configuration is designed to support IP network traffic with basic security for the specified scenario.

The following scenarios are described:

- Scenario 1—Remote Offices and Telecommuters Dialing In to a Central Site

- Scenario 2—Bidirectional Dial Between Central Sites and Remote Offices

- Scenario 3—Telecommuters Dialing In to a Mixed Protocol Environment

Note If you use Token card-based security in your dial network, we recommend that you enable Password Authentication Protocol (PAP) authentication and disable the Multilink protocol to maximize dial-in performance.

Remote User Demographics

Employees stationed in remote offices or disparate locations often dial in to central sites or headquarter offices to download or upload files and check e-mail. These employees often dial in to the corporate network from a remote office LAN using ISDN or from another location such as a hotel room using a modem.

The following remote enterprise users typically dial in to enterprise networks:

- Full-time telecommuters—Employees using stationary workstations to dial in from a small office, home office (SOHO), making ISDN connections with terminal adapters or PC cards through the public telephone network, and operating at higher speeds over the network, which rules out the need for a modem.

- Travelers—Employees such as salespeople that are not in a steady location for more than 30 percent of the time usually dial in to the network with a laptop and modem through the public telephone network, and primarily access the network to check E-mail or transfer a few files.

- Workday extenders—Employees that primarily work in the company office, occasionally dial in to the enterprise with a mobile or stationary workstation plus modem, and primarily access the network to check E-mail or transfer a few files.

Demand and Scalability

You need to evaluate scalability and design issues before you build a dial enterprise network. As the number of company employees increases, the number of remote users who need to dial in increases. A good dial solution scales upward as the demand for dial-in ports grows. For example, it is not uncommon for a fast-growing enterprise to grow from a demand of 100 modems to 250 modems in less than one year.

You should always maintain a surplus of dial-in ports to accommodate company growth and occasional increases in access demand. In the early stages of a fast-growing company that has 100 modems installed for 6000 registered remote users, only 50 to 60 modems might be active at the same time. As demand grows over one year, 250 modems might be installed to support 10,000 registered token card holders.

During special company occasions, such as worldwide conventions, demand for remote access can also increase significantly. During such activities, dial-in lines are used heavily throughout the day and evening by remote sales people using laptops to access E-mail and share files. This behavior is indicative of sales people working away from their home territories or sales offices. Network administrators need to prepare for these remote access bursts, which cause significant increases for remote access demand.

Remote Offices and Telecommuters Dialing In to a Central Site

Remote office LANs typically dial in to other networks using ISDN. Remote offices that use Frame Relay require a more costly dedicated link.

Connections initiated by remote offices and telecommuters are brought up on an as-needed basis, which results in substantial cost savings for the company. In dial-on-demand scenarios, users are not connected for long periods of time. The number of remote nodes requiring access is relatively low, and the completion time for the dial-in task is short.

Central sites typically do not dial out to the remote LANs. Instead, central sites respond to calls. Remote sites initiate calls. For example, a field sales office might use ISDN to dial in to and browse a central site’s intranet. Additionally a warehouse comprising five employees can use ISDN to log in to a remote network server to download or upload product order information. For an example of bidirectional dialing, see the section “Bidirectional Dial Between Central Sites and Remote Offices” later in this chapter.

Note Dial-on-demand routing (DDR) uses static routes or snapshot routing. For IP-only configurations, static routes are commonly used for remote dial-in. For Internet Protocol Exchange (IPX) networking, snapshot routing is often used to minimize configuration complexity.

Network Topologies

Figure 1 shows an example of a remote office that places digital calls in to a central site network. The remote office router can be any Cisco router with a BRI physical interface, such as a Cisco 766 or Cisco 1604 router. The central office gateway router can be any Cisco router that supports PRI connections, such as a Cisco 3600 series, Cisco 4000 series, or Cisco 7000 series router.

Figure 1 Remote Office Dialing In to a Central Site

Figure 2 shows an example of a remote office and telecommuter dialing in to a central site. The remote office places digital calls. The telecommuter places analog calls. The remote office router can be any Cisco router with a BRI interface, such as a Cisco 766, Cisco 1604, or Cisco 2503 router. The central office gateway router is a Cisco AS5300 series access server or a Cisco 3640 router, which supports both PRI and analog connections.

Figure 2 Remote Office and Telecommuter Dialing In to a Central Site

Dial-In Scenarios

The configuration examples in the following sections provide different combinations of dial-in scenarios, which can be derived from Figure 1 and Figure 2:

- Cisco 1604 Remote Office Router Dialing In to a Cisco 3620 Access Router

- Remote Office Router Dialing In to a Cisco 3620 Router

- Cisco 700 Series Router Using Port Address Translation to Dial In to a Cisco AS5300 Access Server

- Cisco 3640 Central Site Router Configuration to Support ISDN and Modem Calls

- Cisco AS5300 Central Site Configuration Using Remote Security

Note Be sure to include your own IP addresses, host names, and security passwords where appropriate if you use these examples in your own network.

Cisco 1604 Remote Office Router Dialing In to a Cisco 3620 Access Router

This section provides a common configuration for a Cisco 1604 remote office router dialing in to a Cisco 3620 access router positioned at a central enterprise site. Only ISDN digital calls are supported in this scenario. No analog modem calls are supported. All calls are initiated by the remote router on an as-needed basis. The Cisco 3620 router is not set up to dial out to the Cisco 1604 router. (Refer to Figure 1.)

The Cisco 1604 and Cisco 3620 routers use the IP unnumbered address configurations, MLP, and the dial-load threshold feature, which brings up the second B channel when the first B channel exceeds a certain limit. Because static routes are used, a routing protocol is not configured. A default static route is configured on the Cisco 1604 router, which points back to the central site. The central site also has a static route that points back to the remote LAN. Static route configurations assume that you have only one LAN segment at each remote office.

Cisco 1604 Router Configuration

The following configuration runs on the Cisco 1604 router, shown in Figure 1. This SOHO router places digital calls in to the Cisco 3620 central site access router. See the next example for the running configuration of the Cisco 3620 router.

version xx.x

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

no service udp-small-servers

no service tcp-small-servers

!

hostname remotelan1

!

enable secret cisco

!

username NAS password dialpass

username admin password cisco

isdn switch-type basic-5ess

!

interface Ethernet0

ip address 10.2.1.1 255.255.255.0

!

interface BRI0

ip unnumbered Ethernet0

encapsulation ppp

dialer map ip 10.1.1.10 name NAS 5551234

dialer load-threshold 100 either

dialer-group 1

no fair-queue

ppp authentication chap pap callin

ppp multilink

!

ip classless

ip route 0.0.0.0 0.0.0.0 10.1.1.10

ip route 10.1.1.10 255.255.255.255 BRI0

dialer-list 1 protocol ip permit

!

line con 0

line vty 0 4

login local

!

end

Cisco 3620 Router Configuration

The following sample configuration runs on the Cisco 3620 router shown in Figure 1. This modular access router has one 2-port PRI network module installed in slot 1 and one 1-port Ethernet network module installed in slot 0. The router receives only digital ISDN calls from the Cisco 1604 router. The configuration for the Cisco 1604 router was provided in the previous example.

version xx.x

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

no service udp-small-servers

no service tcp-small-servers

!

hostname NAS

!

aaa new-model

aaa authentication login default local

aaa authentication login console enable

aaa authentication login vty local

aaa authentication login dialin local

aaa authentication ppp default local

aaa authentication ppp dialin if-needed local

enable secret cisco

!

username admin password cisco

username remotelan1 password dialpass

async-bootp dns-server 10.1.3.1 10.1.3.2

isdn switch-type primary-5ess

!

controller T1 1/0

framing esf

clock source line

linecode b8zs

pri-group timeslots 1-24

!

controller T1 1/1

framing esf

clock source line

linecode b8zs

pri-group timeslots 1-24

!

interface Loopback0

ip address 10.1.2.254 255.255.255.0

!

interface Ethernet 0/0

ip address 10.1.1.10 255.255.255.0

ip summary address eigrp 10 10.1.2.0 255.255.255.0

!

interface Serial 1/0:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Serial 1/1:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Dialer0

ip unnumbered Loopback0

no ip mroute-cache

encapsulation ppp

peer default ip address pool dialin_pool

dialer in-band

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap pap dialin

ppp multilink

!

router eigrp 10

network 10.0.0.0

passive-interface Dialer0

default-metric 64 100 250 100 1500

redistribute static

no auto-summary

!

ip local pool dialin_pool 10.1.2.1 10.1.2.50

ip default-gateway 10.1.1.1

ip route 10.2.1.1 255.255.255.255 Dialer0

ip route 10.2.1.0 255.255.255.0 10.2.1.1

ip classless

!

dialer-list 1 protocol ip permit

!

line con 0

login authentication console

line aux 0

login authentication console

line vty 0 4

login authentication vty

transport input telnet rlogin

!

end

Remote Office Router Dialing In to a Cisco 3620 Router

This section provides a common configuration for a Cisco 700 or 800 series remote office router placing digital calls in to a Cisco 3620 router positioned at a central enterprise site. All calls are initiated by the remote router on an as-needed basis. The Cisco 3620 router is not set up to dial out to the remote office router. (See Figure 1.)

Cisco 700 Series Router Configuration

The following configuration task is for a Cisco 700 series ISDN router placing digital calls in to a central site router that supports ISDN PRI, such as the Cisco 3620 router. In this scenario, ISDN unnumbered interfaces with static routes are pointing back to the Cisco 3620.

command.

Command

Purpose

Step 1

At the system prompt level, specifies the host name of the router, which is also used when responding to Challenge Handshake Authentication Protocol (CHAP) authentication with the Cisco 3620. For CHAP authentication, the system’s name must match the username configured on the Cisco 3620.

Step 2

Sets the transmit and receive password for the client. This is the password which is used in response to CHAP authentication requests, and it must match the username password configured on the Cisco 3620 router.

Step 3

Sets PPP encapsulation for incoming and outgoing authentication instead of CPP.

Step 4

Enables Multilink PPP (MLP).

Step 5

Creates the profile named nas, which is reserved for the Cisco 3620 router.

Step 6

Specifies the LAN IP address. The sequence 0.0.0.0 means that it will use the address assigned to it from the central Cisco 3620 router. See Step 14.

Step 7

Configures the profiles to not use Ethernet framing.

Step 8

Cisco 3620 router.

Step 9

Sets the idle time at which the B channel will be dropped. In this case, the line is dropped after 300 seconds of idle time.

Step 10

Sets the number to call when dialing out of the first and second B channel.

Step 11

Enters LAN profile mode.

Step 12

Turns bridging off.

Step 13

Turns on IP routing.

Step 14

Sets the LAN IP address for the interface.

After you configure the Cisco 760 or Cisco 770 series router, the final configuration should resemble the following:

set systemname remotelan1

set ppp secret client

set encapsulation ppp

set ppp multilink on

cd lan

set bridging off

set ip routing on

set ip 10.2.1.1

set subnet 255.255.255.0

set user nas

set bridging off

set ip 0.0.0.0

set ip netmask 0.0.0.0

set ip framing none

set ip route destination 0.0.0.0 gateway 10.1.1.10

set timeout 300

set 1 number 5551234

set 2 number 5551234

The previous software configuration does not provide for any access security. To provide access security, use the following optional commands in EXEC mode:

Command

Purpose

Provides CHAP authentication to incoming calls.

Requires the calling parties number to be matched against the configured receive numbers (such as set by the set callidreceive # command). This command also denies all incoming calls if no callidreceive number is configured.

Specifies a remote system password, which enables you to make changes on the router from a remote location.

Specifies a local system password, which enables you to make changes on the router from a local console connection.

Sets the system password for the previous access configurations.

Cisco 3620 Router Configuration

The following example provides a sample configuration for the Cisco 3620 router. This modular access router has one 2-port PRI network module installed in slot 1 and one 1-port Ethernet network module installed in slot 0. The router receives only digital ISDN calls over T1 lines from the Cisco 700 series remote office router, which was described in the previous example.

version xx.x

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

no service udp-small-servers

no service tcp-small-servers

hostname NAS

!

aaa new-model

aaa authentication login default local

aaa authentication login console enable

aaa authentication login vty local

aaa authentication login dialin local

aaa authentication ppp default local

aaa authentication ppp dialin if-needed local

enable secret cisco

!

username admin password cisco

username remotelan1 password dialpass

!

async-bootp dns-server 10.1.3.1 10.1.3.2

isdn switch-type primary-5ess

!

controller T1 1/0

framing esf

clock source line

linecode b8zs

pri-group timeslots 1-24

!

controller T1 1/1

framing esf

clock source line

linecode b8zs

pri-group timeslots 1-24

!

interface Loopback0

ip address 10.1.2.254 255.255.255.0

!

interface Ethernet 0/0

ip address 10.1.1.10 255.255.255.0

ip summary address eigrp 10 10.1.2.0 255.255.255.0

!

interface Serial 1/0:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Serial 1/1:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Dialer0

ip unnumbered Loopback0

no ip mroute-cache

encapsulation ppp

peer default ip address pool dialin_pool

dialer in-band

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap pap dialin

ppp multilink

!

router eigrp 10

network 10.0.0.0

passive-interface Dialer0

default-metric 64 100 250 100 1500

redistribute static

no auto-summary

!

ip local pool dialin_pool 10.1.2.1 10.1.2.50

ip default-gateway 10.1.1.1

ip route 10.2.1.1 255.255.255.255 Dialer0

ip route 10.2.1.0 255.255.255.0 10.2.1.1

ip classless

!

dialer-list 1 protocol ip permit

!

line con 0

login authentication console

line aux 0

login authentication console

line vty 0 4

login authentication vty

transport input telnet rlogin

!

end

Cisco 700 Series Router Using Port Address Translation to Dial In to a Cisco AS5300 Access Server

This section shows a Cisco 700 series router using the port address translation (PAT) feature to dial in to a Cisco AS5300 central site access server. IP addresses are assigned from the central site, which leverages the PAT feature to streamline multiple devices at the remote site through a single assigned address. In this example, the Cisco 700 series router has a private range of IP addresses used on the Ethernet side. However, the router is able to translate between the local private addresses and the dynamically registered address on the WAN interface. (See Figure 1.)

Cisco 700 Series Configuration

The sample configuration in this section allows PCs on a LAN to boot up and acquire their IP address dynamically from a Cisco 700 series router, which in turn translates the private addresses into a single IP address assigned from a Cisco AS5300 central site router. The Cisco 700 series router also passes information via DHCP regarding the Domain Name System (DNS) server (in this example, 10.2.10.1) and the Windows Internet naming service (WINS) server (in this example, 10.2.11.1) along with the domain name.

A possible sequence of events would be a remote PC running Windows 95 boots up on the Ethernet segment and gets its IP address and network information from the Cisco 700 series router. The PC then opens up Netscape and attempts to view a web page at the central site, which causes the router to dial in to the central site. The router dynamically obtains its address from the central site pool of addresses and uses it to translate between the private address on the local Ethernet segment and the registered IP address borrowed from the central site router.

To configure a remote router, use the following commands beginning in EXEC mode:

Command

Purpose

Step 1

At the system prompt level, specifies the host name of the router, which is also used when responding to CHAP authentication with the Cisco 3620 router. For CHAP authentication, the system’s name must match the username configured on the Cisco 3620.

Step 2

Sets the transmit and receive password for the client. This is the password which is used in response to CHAP authentication requests, and it must match the username password configured on the Cisco 3620 router.

Step 3

Sets PPP encapsulation for incoming and outgoing authentication instead of CPP.

Step 4

Enables MLP.

Step 5

Enables the router to act as a DHCP server and assign addresses from the private network. By default, all DHCP client addresses are assigned from the 10.0.0.0 network.

Step 6

Passes the DNS server IP address to the DHCP client.

Step 7

Passes the IP address of the WINS server to the DHCP client.

Step 8

Sets the DHCP domain name for the Cisco 3620 central site router.

Step 9

Creates the profile named nas, which is setup for the Cisco 3620 router.

Step 10

Enables Port Address Translation (PAT) on the router.

Step 11

Configures the profiles to not use Ethernet framing.

Step 12

Sets the default route to point to the Ethernet IP address of Cisco 3620 router.

Step 13

Sets the number to call when dialing out of the first B channel.

Step 14

Sets the number to call when dialing out of the second B channel.

Step 15

Enters LAN profile mode.

Step 16

Turns bridging off.

Step 17

Turns IP routing on.

After you configure the router, the configuration should resemble the following:

set systemname remotelan1

set encapsulation ppp

set ppp secret client

set ppp multilink on

set dhcp server

set dhcp dns primary 10.2.10.1

set dhcp wins 10.2.11.1

set dhcp domain nas.com

set user nas

set bridging off

set ip routing on

set ip framing none

set ip pat on

set ip route destination 0.0.0.0 gateway 10.1.1.0

set 1 number 5551234

set 2 number 5551234

Cisco AS5300 Router Configuration

The following example configures a Cisco AS5300 router for receiving calls from the router in the previous example.

Note This configuration can also run on a Cisco 4000, Cisco 3600, or Cisco 7000 series router. However, the interface numbering scheme for these routers will be in the form of slot/port. Additionally, the clocking will be set differently. Refer to your product configuration guides and configuration notes for more details.

!

version xx.x

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

no service udp-small-servers

no service tcp-small-servers

!

hostname NAS

!

aaa new-model

aaa authentication login default local

aaa authentication login console enable

aaa authentication login vty local

aaa authentication login dialin local

aaa authentication ppp default local

aaa authentication ppp dialin if-needed local

enable secret cisco

!

username admin password cisco

username remotelan1 password dialpass

!

async-bootp dns-server 10.1.3.1 10.1.3.2

isdn switch-type primary-5ess

!

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

!

interface Loopback0

ip address 10.1.2.254 255.255.255.0

!

interface Ethernet0

ip address 10.1.1.10 255.255.255.0

ip summary address eigrp 10 10.1.2.0 255.255.255.0

!

interface Serial0

no ip address

shutdown

!

interface Serial1

no ip address

shutdown

!

interface Serial0:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Serial1:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Dialer0

ip unnumbered Loopback0

no ip mroute-cache

encapsulation ppp

peer default ip address pool dialin_pool

dialer in-band

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap pap dialin

ppp multilink

!

router eigrp 10

network 10.0.0.0

passive-interface Dialer0

default-metric 64 100 250 100 1500

redistribute static

no auto-summary

!

ip local pool dialin_pool 10.1.2.1 10.1.2.50

ip default-gateway 10.1.1.1

ip route 10.2.1.1 255.255.255.255 Dialer0

ip route 10.2.1.0 255.255.255.0 10.2.1.1

ip classless

!

dialer-list 1 protocol ip permit

!

line con 0

login authentication console

line aux 0

login authentication console

line vty 0 4

login authentication vty

transport input telnet rlogin

!

end

In this configuration, the local pool is using a range of unused addresses on the same subnet on which the Ethernet interface is configured. The addresses will be used for the remote devices dialing in to the Cisco AS5300 access server.

Cisco 3640 Central Site Router Configuration to Support ISDN and Modem Calls

The following configuration allows remote LANs and standalone remote users with modems to dial in to a central site. Figure 2 shows the network topology.

The Cisco 3640 router has the following hardware configuration for this scenario:

- One 2-port ISDN-PRI network module installed in slot 1.

- One digital modem network module installed in slot 2 and slot 3.

- One 1-port Ethernet network module installed in slot 0.

Note Each MICA technologies digital modem card has its own group async configuration. Additionally, a single range of asynchronous lines is used for each modem card. For additional interface numbering information, refer to the document Digital Modem Network Module Configuration Note.

version xx.x

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

no service udp-small-servers

no service tcp-small-servers

!

hostname NAS

!

aaa new-model

aaa authentication login default local

aaa authentication login console enable

aaa authentication login vty local

aaa authentication login dialin local

aaa authentication ppp default local

aaa authentication ppp dialin if-needed local

enable secret cisco

!

username admin password cisco

username remotelan1 password dialpass1

username remotelan2 password dialpass2

username PCuser1 password dialpass3

username PCuser2 password dialpass4

!

async-bootp dns-server 10.1.3.1 10.1.3.2

isdn switch-type primary-5ess

!

controller T1 1/0

framing esf

clock source line

linecode b8zs

pri-group timeslots 1-24

!

controller T1 1/1

framing esf

clock source line

linecode b8zs

pri-group timeslots 1-24

!

interface Loopback0

ip address 10.1.2.254 255.255.255.0

!

interface Ethernet0/0

ip address 10.1.1.10 255.255.255.0

ip summary address eigrp 10 10.1.2.0 255.255.255.0

!

interface Serial 1/0:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Serial 1/1:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Group-Async1

ip unnumbered Loopback0

encapsulation ppp

async mode interactive

peer default ip address pool dialin_pool

no cdp enable

ppp authentication chap pap dialin

group-range 65 88

!

interface Group-Async2

ip unnumbered Loopback0

encapsulation ppp

async mode interactive

peer default ip address pool dialin_pool

no cdp enable

ppp authentication chap pap dialin

group-range 97 120

!

interface Dialer0

ip unnumbered Loopback0

no ip mroute-cache

encapsulation ppp

peer default ip address pool dialin_pool

dialer in-band

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap pap dialin

ppp multilink

!

router eigrp 10

network 10.0.0.0

passive-interface Dialer0

no auto-summary

!

ip local pool dialin_pool 10.1.2.1 10.1.2.50

ip default-gateway 10.1.1.1

ip classless

!

dialer-list 1 protocol ip permit

!

line con 0

login authentication console

line 65 88

autoselect ppp

autoselect during-login

login authentication dialin

modem DialIn

line 97 120

autoselect ppp

autoselect during-login

login authentication dialin

modem DialIn

line aux 0

login authentication console

line vty 0 4

login authentication vty

transport input telnet rlogin

!

end

Cisco AS5300 Central Site Configuration Using Remote Security

.

Central Site Cisco AS5300 Configuration Using TACACS+ Authentication

The following example assumes that you are running TACACS+ on the remote security server:

version xx.x

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

no service udp-small-servers

no service tcp-small-servers

!

hostname NAS

!

aaa new-model

aaa authentication login console enable

aaa authentication login vty tacacs+

aaa authentication login dialin tacacs+

aaa authentication ppp default tacacs+

aaa authentication ppp dialin if-needed tacacs+

enable secret cisco

!

async-bootp dns-server 10.1.3.1 10.1.3.2

isdn switch-type primary-5ess

!

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

!

interface Loopback0

ip address 10.1.2.254 255.255.255.0

!

interface Ethernet0

ip address 10.1.1.10 255.255.255.0

ip summary address eigrp 10 10.1.2.0 255.255.255.0

!

interface Serial0

no ip address

shutdown

!

interface Serial1

no ip address

shutdown

!

interface Serial0:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Serial1:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Group-Async1

ip unnumbered Loopback0

encapsulation ppp

async mode interactive

peer default ip address pool dialin_pool

no cdp enable

ppp authentication chap pap dialin

group-range 1 48

!

interface Dialer0

ip unnumbered Loopback0

no ip mroute-cache

encapsulation ppp

peer default ip address pool dialin_pool

dialer in-band

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap pap dialin

ppp multilink

!

router eigrp 10

network 10.0.0.0

passive-interface Dialer0

redistribute static

default-metric 64 100 250 100 1500

no auto-summary

!

ip local pool dialin_pool 10.1.2.1 10.1.2.50

ip default-gateway 10.1.1.1

ip classless

!

dialer-list 1 protocol ip permit

!

line con 0

login authentication console

line 1 48

autoselect ppp

autoselect during-login

login authentication dialin

modem DialIn

line aux 0

login authentication console

line vty 0 4

login authentication vty

transport input telnet rlogin

end

TACACS+ Security Server Entry

The following example can be configured on a remote TACACS+ security server, which complements the Cisco AS5300 access server configuration listed in the previous example:

user = remotelan1 {

chap = cleartext "dialpass1"

service = ppp protocol = ip {

addr = 10.2.1.1

route = "10.2.1.0 255.255.255.0"

}

}

user = PCuser1 {

login = cleartext "dialpass2"

chap = cleartext "dialpass2"

service = ppp protocol = ip {

addr-pool = dialin_pool

}

service = exec {

autocmd = "ppp negotiate"

}

}

user = PCuser2 {

login = cleartext "dialpass3"

chap = cleartext "dialpass3"

service = ppp protocol = ip {

addr-pool = dialin_pool

}

service = exec {

autocmd = "ppp negotiate"

}

Bidirectional Dial Between Central Sites and Remote Offices

Sometimes a gateway access server at headquarters is required to dial out to a remote site while simultaneously receiving incoming calls. This type of network is designed around a specific business support model.

Dial-In and Dial-Out Network Topology

Figure 3 shows a typical dial-in and dial-out network scenario, which amounts to only 25 percent of all dial topologies. The Cisco AS5300 access server at headquarters initiates a connection with a Cisco 1604 router at remote office 1. After a connection is established, the file server at the remote site (shown as Inventory child host) runs a batch processing application with the mainframe at headquarters (shown as Inventory totals parent host). While files are being transferred between remote office 1 and headquarters, remote office 2 is successfully dialing in to headquarters.

Figure 3 Headquarters Configured for Dial-In and Dial-out Networking

There are some restrictions for dial-out calling. Dial-out analog and digital calls are commonly made to remote ISDN routers, such as the Cisco 1604 router. On the whole, dial out calls are not made from a central site router to a remote PC but rather from a remote PC in to the central site. However, central site post offices often call remote office routers on demand to deliver E-mail. Callback is enabled on dial-in scenarios only. The majority of a dial out software configuration is setup on the router at headquarters, not the remote office router. Dialing out to a stack group of multiple chassis is not supported by Cisco IOS software. Note that Multichassis Multilink PPP (MMP) and virtual private dialup networks (VPDNs) are dial-in only solutions.

Dialer Profiles and Virtual Profiles

Profiles are set up to discriminate access on a user-specific basis. For example, if the chief network administrator is dialing in to the enterprise, a unique user profile can be created with an idle timeout of one year, and universal access privileges to all networks in the company. For less fortunate users, access can be restricted to an idle timeout of 10 seconds and network connections setup for only a few addresses.

Depending on the size and scope of your dial solution, you can set up two different types of profiles: dialer profiles or virtual profiles. Dialer profiles are individual user profiles set up on routers or access servers in a small-scale dial solution. This type of profile is configured locally on the router and is limited by the number of interfaces that exist on the router. When an incoming call comes into the dial pool, the dialer interface binds the caller to a dialer profile via the caller ID or the caller name.

Figure 4 shows an example of how dialer profiles can be used when:

- You need to bridge over multiple ISDN channels.

- You want to use ISDN to back up a WAN link, but still have the ISDN interface available during those times that the WAN link is up.

- A security server, such as a AAA TACACS or RADIUS server, is not available for use.

Note For more information about dialer profiles, see the chapters “Configuring Peer-to-Peer DDR with Dialer Profiles” and “Configuring Dial Backup with Dialer Profiles.”

Figure 4 Dial-In Scenario for Dialer Profiles

Virtual profiles are user-specific profiles for large-scale dial solutions; however, these profiles are not manually configured on each router or access server. A virtual profile is a unique PPP application that can create and configure a virtual access interface dynamically when a dial-in call is received, and tear down the interface dynamically when the call ends.

The configuration information for a virtual access interface in a virtual profile can come from the virtual template interface, or from user-specific configuration information stored on an AAA server, or both. The virtual profile user-specific configuration stored on the AAA server is identified by the authentication name for the call-in user. (That is, if the AAA server authenticates the user as samson, the user-specific configuration is listed under samson in the AAA user file.) The virtual profile user-specific configuration should include only the configuration that is not shared by multiple users. Shared configuration should be placed in the virtual template interface, where it can be cloned on many virtual access interfaces as needed.

AAA configurations are much easier to manage for large numbers of dial-in users. Virtual profiles can span across a group of access servers, but a AAA server is required. Virtual profiles are set up independently of which access server, interface, or port number users connect to. For users that share duplicate configuration information, it is best to enclose the configuration in a virtual template. This requirement eliminates the duplication of commands in each of the user records on the AAA server.

configuration (such as access lists and route filters) downloaded during NCP negotiations.

Figure 5 shows an example of how virtual profiles are used:

- A large-scale dial-in solution is available, which includes many access servers or routers (for example, three or more devices stacked together in an MMP scenario).

- Discrimination between large numbers of users is needed.

- Setup and maintenance of a user profile for each dial-in user on each access server or router is much too time consuming.

- A security server, such as a AAA TACACS or RADIUS server, is available for use.

Note For a virtual profile configuration example, see the section “Large-Scale Dial-In Configuration Using Virtual Profiles” later in this chapter. For more information about virtual profiles, see the chapters “Configuring Virtual Profiles” and “Configuring Per-User Configuration” in this publication.

Figure 5 Dial-In Scenario for Virtual Profiles

Running Access Server Configurations

In most cases, dialer profiles are configured on access servers or routers that receive calls and must discriminate between users, such as many different remote routers dialing in. (See Figure 6.)

Figure 6 Remote Cisco 1600s Dialing In to a Cisco AS5300 at the Central Site

make calls.

The configurations examples in the following section are provided for different types of dial scenarios, which can be derived from Figure 3 through Figure 6:

- Examples with dialer profiles:

– Cisco AS5300 Access Server Configuration with Dialer Profiles

– Cisco 1604 ISDN Router Configuration with Dialer Profiles

– Cisco 1604 Router Asynchronous Configuration with Dialer Profiles

- Examples without dialer profiles:

– Cisco AS5300 Access Server Configuration Without Dialer Profiles

– Cisco 1604 ISDN Router Configuration Without Dialer Profiles

– Cisco 1604 Router Asynchronous Configuration Without Dialer Profiles

- Large-Scale Dial-In Configuration Using Virtual Profiles

Note Be sure to include your own IP addresses, host names, and security passwords where appropriate if configuring these examples in your network.

Cisco AS5300 Access Server Configuration with Dialer Profiles

The following bidirectional dial configuration runs on the Cisco AS5300 access server at headquarters in Figure 3. This configuration enables calls to be sent to the SOHO router and received from remote hosts and clients. The calling is bidirectional.

version xx.x

service udp-small-servers

service tcp-small-servers

!

hostname 5300

!

aaa new-model

aaa authentication login default local

aaa authentication login console enable

aaa authentication login vty local

aaa authentication login dialin local

aaa authentication ppp default local

aaa authentication ppp dialin if-needed local

enable secret cisco

!

username async1 password cisco

username async2 password cisco

username async3 password cisco

username async4 password cisco

username async5 password cisco

username async6 password cisco

username async7 password cisco

username async8 password cisco

username isdn1 password cisco

username isdn2 password cisco

username isdn3 password cisco

username isdn4 password cisco

username isdn5 password cisco

username isdn6 password cisco

username isdn7 password cisco

username isdn8 password cisco

username DialupAdmin password cisco

!

isdn switch-type primary-dms100

chat-script cisco-default ABORT ERROR "" "AT" OK "ATDT\T" TIMEOUT 60 CONNECT

!

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

!

interface loopback 1

ip address 172.18.38.40 255.255.255.128

!

interface loopback 2

ip address 172.18.38.130 255.255.255.128

!

interface Ethernet0

ip address 172.18.39.40 255.255.255.0

no ip mroute-cache

ip ospf priority 0

!

interface Serial0:23

no ip address

no ip mroute-cache

encapsulation ppp

isdn incoming-voice modem

dialer pool-member 2

!

interface Serial1:23

no ip address

no ip mroute-cache

encapsulation ppp

isdn incoming-voice modem

dialer pool-member 2

!

interface Group-Async1

no ip address

no ip mroute-cache

encapsulation ppp

async mode interactive

dialer in-band

dialer pool-member 1

ppp authentication chap pap

group-range 1 48

!

interface Dialer10

ip unnumbered loopback 1

encapsulation ppp

peer default ip address dialin_pool

dialer remote-name async1

dialer string 14085268983

dialer hold-queue 10

dialer pool 1

dialer-group 1

ppp authentication pap chap callin

ppp pap sent-username DialupAdmin password 7 07063D11542

!

interface Dialer11

ip unnumbered loopback 1

encapsulation ppp

no peer default ip address pool

dialer remote-name async2

dialer string 14085262012

dialer hold-queue 10

dialer pool 1

dialer-group 1

ppp authentication pap chap callin

ppp pap sent-username DialupAdmin password 7 07063D11542

!

interface Dialer12

ip unnumbered loopback 1

encapsulation ppp

no peer default ip address pool

dialer remote-name async3

dialer string 14085260706

dialer hold-queue 10

dialer pool 1

dialer-group 1

ppp authentication pap chap callin

ppp pap sent-username DialupAdmin password 7 07063D11542

!

interface Dialer13

ip unnumbered loopback 1

encapsulation ppp

no peer default ip address pool

dialer remote-name async4

dialer string 14085262731

dialer hold-queue 10

dialer pool 1

dialer-group 1

ppp authentication pap chap callin

ppp pap sent-username DialupAdmin password 7 07063D11542

!

interface Dialer14

ip unnumbered loopback 1

encapsulation ppp

no peer default ip address pool

dialer remote-name async5

dialer string 14085264431

dialer hold-queue 10

dialer pool 1

dialer-group 1

ppp authentication pap chap callin

ppp pap sent-username DialupAdmin password 7 07063D11542

!

interface Dialer15

ip unnumbered loopback 1

encapsulation ppp

no peer default ip address pool

dialer remote-name async6

dialer string 14085261933

dialer hold-queue 10

dialer pool 1

dialer-group 1

ppp authentication pap chap callin

ppp pap sent-username DialupAdmin password 7 07063D11542

!

interface Dialer16

ip unnumbered loopback 1

encapsulation ppp

no peer default ip address pool

dialer remote-name async7

dialer string 14085267631

dialer hold-queue 10

dialer pool 1

dialer-group 1

ppp authentication pap chap callin

ppp pap sent-username DialupAdmin password 7 07063D11542

!

interface Dialer17

ip unnumbered loopback 2

encapsulation ppp

no peer default ip address pool

dialer remote-name async8

dialer string 14085265153

dialer hold-queue 10

dialer pool 2

dialer-group 1

ppp authentication chap pap

!

interface Dialer18

ip unnumbered loopback 2

encapsulation ppp

no peer default ip address pool

dialer remote-name isdn1

dialer string 14085267887

dialer hold-queue 10

dialer pool 2

dialer-group 1

ppp authentication chap pap

!

interface Dialer19

ip unnumbered loopback 2

encapsulation ppp

no peer default ip address pool

dialer remote-name isdn2

dialer string 14085261591

dialer hold-queue 10

dialer pool 2

dialer-group 1

ppp authentication chap pap

!

interface Dialer20

ip unnumbered loopback 2

encapsulation ppp

no peer default ip address pool

dialer remote-name isdn3

dialer string 14085262118

dialer hold-queue 10

dialer pool 2

dialer-group 1

ppp authentication chap pap

!

interface Dialer21

ip unnumbered loopback 2

encapsulation ppp

no peer default ip address pool

dialer remote-name isdn4

dialer string 14085263757

dialer hold-queue 10

dialer pool 2

dialer-group 1

ppp authentication chap pap

!

interface Dialer22

ip unnumbered loopback 2

encapsulation ppp

no peer default ip address pool

dialer remote-name isdn5

dialer string 14085263769

dialer hold-queue 10

dialer pool 2

dialer-group 1

ppp authentication chap pap

!

interface Dialer23

ip unnumbered loopback 2

encapsulation ppp

no peer default ip address pool

dialer remote-name isdn6

dialer string 14085267884

dialer hold-queue 10

dialer pool 2

dialer-group 1

ppp authentication chap pap

!

interface Dialer24

ip unnumbered loopback 2

encapsulation ppp

no peer default ip address pool

dialer remote-name isdn7

dialer string 14085267360

dialer hold-queue 10

dialer pool 2

dialer-group 1

ppp authentication chap pap

!

interface Dialer25

ip unnumbered loopback 2

encapsulation ppp

no peer default ip address pool

dialer remote-name isdn8

dialer string 14085260361

dialer hold-queue 10

dialer pool 2

dialer-group 1

ppp authentication chap pap

!

router ospf 1

redistribute static subnets

passive-interface Dialer1

passive-interface Dialer2

network 172.18.0.0 0.0.255.255 area 0

!

ip local pool dialin_pool 10.1.2.1 10.1.2.50

ip domain-name cisco.com

ip classless

!

dialer-list 1 protocol ip permit

!

line con 0

exec-timeout 0 0

line 1 24

no exec

exec-timeout 0 0

autoselect during-login

autoselect ppp

script dialer cisco-default

login local

modem InOut

modem autoconfigure type microcom_hdms

transport input telnet

line aux 0

line vty 0 1

exec-timeout 60 0

password cisco

login

line vty 2 5

exec-timeout 5 0

password cisco

login

!

end

Cisco 1604 ISDN Router Configuration with Dialer Profiles

The following configuration runs on the remote office Cisco 1604 router, which receives calls from the Cisco AS5300 central site access server. (See Figure 3.)

version xx.x

service udp-small-servers

service tcp-small-servers

!

hostname isdn1

!

enable password cisco

!

username 5300 password cisco

username isdn1 password cisco

isdn switch-type basic-5ess

!

interface Ethernet0

ip address 172.18.40.1 255.255.255.0

!

interface BRI0

no ip address

encapsulation ppp

dialer pool-member 1

ppp authentication chap pap

!

interface Dialer1

ip address 172.18.38.131 255.255.255.128

encapsulation ppp

no peer default ip address pool

dialer remote-name 5300

dialer string 14085269328

dialer hold-queue 10

dialer pool 2

dialer-group 1

ppp authentication chap pap

!

ip classless

ip route 0.0.0.0 0.0.0.0 172.18.38.130

dialer-list 1 protocol ip permit

!

line con 0

line vty 0 4

password cisco

login

password cisco

login

!

end

Cisco 1604 Router Asynchronous Configuration with Dialer Profiles

The following asynchronous configuration runs on the remote office Cisco 1604 router, which receives calls from the Cisco AS5300 central site access server. (See Figure 3.)

version xx.x

service udp-small-servers

service tcp-small-servers

!

hostname async1

!

enable password cisco

!

username 5300 password cisco

username async1 password cisco

chat script dial_out ““ “ATDT\T” timeout 60 connect \c

!

interface Ethernet0

ip address 172.18.41.1 255.255.255.0

!

interface serial 0

physical-layer async

no ip address

encapsulation ppp

dialer pool-member 1

ppp authentication chap pap

!

interface Dialer10

ip address 172.18.38.41 255.255.255.128

encapsulation ppp

no peer default ip address pool

dialer remote-name 5300

dialer string 14085269328

dialer hold-queue 10

dialer pool 1

dialer-group 1

ppp authentication chap pap

!

ip classless

ip route 0.0.0.0 0.0.0.0 172.18.38.40

dialer-list 1 protocol ip permit

!

line con 0

line 1

password cisco

login

script modem dial_out

!

end

Cisco AS5300 Access Server Configuration Without Dialer Profiles

The following bidirectional dial configuration runs on the Cisco AS5300 access server at headquarters in Figure 3. This configuration enables calls to be sent to the SOHO router and received from remote hosts and clients. The calling is bidirectional.

version xx.x

service udp-small-servers

service tcp-small-servers

!

hostname 5300

!

aaa new-model

aaa authentication login default local

aaa authentication login console enable

aaa authentication login vty local

aaa authentication login dialin local

aaa authentication ppp default local

aaa authentication ppp dialin if-needed local

enable secret cisco

!

username async1 password cisco

username async2 password cisco

username async3 password cisco

username async4 password cisco

username async5 password cisco

username async6 password cisco

username async7 password cisco

username async8 password cisco

username isdn1 password cisco

username isdn2 password cisco

username isdn3 password cisco

username isdn4 password cisco

username isdn5 password cisco

username isdn6 password cisco

username isdn7 password cisco

username isdn8 password cisco

username DialupAdmin password cisco

!

isdn switch-type primary-dms100

chat-script cisco-default ABORT ERROR "" "AT" OK "ATDT\T" TIMEOUT 60 CONNECT

!

controller T1 0

framing esf

clock source line primary

linecode b8zs

pri-group timeslots 1-24

description ISDN Controller 0

!

controller T1 1

framing esf

clock source line secondary

linecode b8zs

pri-group timeslots 1-24

description ISDN Controller 1

!

interface Ethernet0

ip address 172.18.39.40 255.255.255.0

no ip mroute-cache

ip ospf priority 0

!

interface Serial0:23

no ip address

no ip mroute-cache

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 2

!

interface Serial1:23

no ip address

no ip mroute-cache

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 2

!

interface Group-Async1

no ip address

no ip mroute-cache

encapsulation ppp

async dynamic address

async mode interactive

dialer in-band

dialer rotary-group 1

ppp authentication pap callin

ppp pap sent-username HQ5300 password 7 09434678520A

group-range 1 24

!

interface Dialer1

ip address 172.18.38.40 255.255.255.128

encapsulation ppp

no peer default ip address pool

dialer in-band

dialer map ip 172.18.38.41 name async1 14445558983

dialer map ip 172.18.38.42 name async2 14445552012

dialer map ip 172.18.38.43 name async3 14445550706

dialer map ip 172.18.38.44 name async4 14445552731

dialer map ip 172.18.38.45 name async5 14445554431

dialer map ip 172.18.38.46 name async6 14445551933

dialer map ip 172.18.38.47 name async7 14445557631

dialer map ip 172.18.38.48 name async8 14445555153

dialer hold-queue 10

dialer-group 1

ppp authentication pap chap callin

ppp pap sent-username DialupAdmin password 7 07063D11542

!

interface Dialer2

ip address 172.18.38.130 255.255.255.128

encapsulation ppp

no peer default ip address pool

dialer in-band

dialer map ip 172.18.38.131 name isdn1 14445557887

dialer map ip 172.18.38.132 name isdn2 14445551591

dialer map ip 172.18.38.133 name isdn3 14445552118

dialer map ip 172.18.38.134 name isdn4 14445553757

dialer map ip 172.18.38.135 name isdn5 14445553769

dialer map ip 172.18.38.136 name isdn6 14445557884

dialer map ip 172.18.38.137 name isdn7 14445557360

dialer map ip 172.18.38.138 name isdn8 14445550361

dialer hold-queue 10

dialer-group 1

ppp authentication chap pap

ppp multilink

!

router ospf 1

redistribute static subnets

passive-interface Dialer1

passive-interface Dialer2

network 172.18.0.0 0.0.255.255 area 0

!

ip domain-name cisco.com

ip classless

!

dialer-list 1 protocol ip permit

!

line con 0

exec-timeout 0 0

line 1 24

no exec

exec-timeout 0 0

autoselect during-login

autoselect ppp

script dialer cisco-default

login local

modem InOut

modem autoconfigure type microcom_hdms

transport input telnet

line aux 0

line vty 0 1

exec-timeout 60 0

password cisco

login

line vty 2 5

exec-timeout 5 0

password cisco

login

!

end

Cisco 1604 ISDN Router Configuration Without Dialer Profiles

The following configuration runs on the remote office Cisco 1604 router, which dials in to the Cisco AS5300 access server at headquarters in Figure 3. This configuration does not receive calls from the Cisco AS5300 access server.

!

version 11.1

service udp-small-servers

service tcp-small-servers

!

hostname isdn1

!

enable password cisco

!

username 5300 password cisco

username isdn1 password cisco

isdn switch-type basic-5ess

!

interface Ethernet0

ip address 172.18.40.1 255.255.255.0

!

interface BRI0

ip address 172.18.38.131 255.255.255.128

encapsulation ppp

dialer map ip 172.18.38.130 name 5300 14085269328

dialer-group 1

ppp authentication chap pap

!

ip classless

ip route 0.0.0.0 0.0.0.0 172.18.38.130

dialer-list 1 protocol ip permit

!

line con 0

line vty 0 4

password cisco

login

password cisco

login

!

end

Cisco 1604 Router Asynchronous Configuration Without Dialer Profiles

The following asynchronous configuration runs on the remote office Cisco 1604 router, which dials in to the Cisco AS5300 access server at headquarters in Figure 3. This configuration does not receive calls from the Cisco AS5300 access server.

version xx.x

service udp-small-servers

service tcp-small-servers

!

hostname async1

!

enable password cisco

!

username 5300 password cisco

username async1 password cisco

chat script dial_out ““ “ATDT\T” timeout 60 connect \c

!

interface Ethernet0

ip address 172.18.41.1 255.255.255.0

!

interface serial 0

physical-layer async

ip address 172.18.38.41 255.255.255.128

encapsulation ppp

dialer in-band

dialer map ip 172.18.38.40 name 5300 modem-script dial_out 14085559328

dialer-group 1

ppp authentication chap pap

!

ip classless

ip route 0.0.0.0 0.0.0.0 172.18.38.40

dialer-list 1 protocol ip permit

!

line con 0

line 1

password cisco

login

password cisco

login

!

end

Large-Scale Dial-In Configuration Using Virtual Profiles

The following example is used on each central site stack member shown in Figure 5. This configuration is for a large-scale dial-in scenario.

aaa new-model

aaa authentication login default none

aaa authentication ppp default radius

aaa authentication ppp admin local

aaa authorization network radius

isdn switch-type primary-5ess

!

interface Serial0:23

no ip address

no ip mroute-cache

no cdp enable

ppp authentication chap

!

tacacs-server host 172.18.203.45

virtual-profile aaa

The following example configures an entry running on a RADIUS security server, which is queried by each central site stack member when a call comes in. This entry includes the virtual profile configuration information for remote users dialing in to the central site stack solution.

In this example, virtual profiles are configured by both virtual templates and AAA configuration. John and Rick can dial in from anywhere and have their same keepalive settings and their own IP addresses.

The remaining attribute-value pair settings are not used by virtual profiles. They are the network-protocol access lists and route filters used by AAA-based per-user configuration.

In the AAA configuration cisco-avpair lines, “\n” is used to indicate the start of a new Cisco IOS command line.

john Password = “welcome”

User-Service-Type = Framed-User,

Framed-Protocol = PPP,

cisco-avpair = “lcp:interface-config=keepalive 75\nip address 100.100.100.100 255.255.255.0”,

cisco-avpair = “ip:rte-fltr-out#0=router igrp 60”,

cisco-avpair = “ip:rte-fltr-out#3=deny 171.0.0.0 0.255.255.255”,

cisco-avpair = “ip:rte-fltr-out#4=deny 172.0.0.0 0.255.255.255”,

cisco-avpair = “ip:rte-fltr-out#5=permit any”

rick Password = “emoclew”

User-Service-Type = Framed-User,

Framed-Protocol = PPP,

cisco-avpair = “lcp:interface-config=keepalive 100\nip address 200.200.200.200 255.255.255.0”,

cisco-avpair = “ip:inacl#3=permit ip any any precedence immediate”,

cisco-avpair = “ip:inacl#4=deny igrp 0.0.1.2 255.255.0.0 any”,

cisco-avpair = “ip:outacl#2=permit ip any any precedence immediate”,

cisco-avpair = “ip:outacl#3=deny igrp 0.0.9.10 255.255.0.0 any”

Telecommuters Dialing In to a Mixed Protocol Environment

The scenario in this section describes how to provide remote access to employees who dial in to a mixed protocol enterprise network. The sample configurations provided in this section assume that enterprise telecommuters are dialing in with modems or terminal adapters from outside the LAN at headquarters.

The following sections are provided:

- Description

- Enterprise Network Topology

- Mixed Protocol Dial-In Scenarios

Description

.) For example, an enterprise might deploy an IP base across the entire intranet while still allowing file sharing with other protocols such as AppleTalk and AppleTalk Remote Access (ARA).

Figure 7 Large Enterprise with a Multiprotocol Network

Table 1 Typical Mixed Protocol Environment

Applications

Running on the Network Server

Remote or Local

Client Applications

Protocol Used

to Support

the Network

Internal Supporting Department

Windows NT

Windows 95 or Windows 3.1 running on PCs

IP

Marketing, human resources, engineering, and customer support

UNIX

SunOS or Solaris running on a UNIX-based workstation or NCD

IP

Engineering and customer support

AppleTalk

Mac OS System Software 7.5 running on Macintosh computers

AppleTalk

Documentation and creative services

NetWare

Novell NetWare client software

IPX

Marketing, and human resources, engineering, customer support

Enterprise Network Topology

Figure 8 shows a sample enterprise network, which supports 10,000 registered token card holders. Some registered users might use their access privileges each day, while others might use their access privileges very infrequently, such as only on business trips. The dial-in access provisioned for outsiders, such as partners or vendors, is supported separately in a firewalled setup.

Five Cisco AS5300 access servers are positioned to provide 250 dial-in ports for incoming modem calls. A Catalyst 1900 is used as a standalone switch to provide Ethernet switching between the Cisco AS5300 access servers and the 100BASET interfaces on the backbone routers. Two Cisco 7200 series routers are used to reduce the processing workload on the access servers and provide access to the company’s backbone. If the Cisco 7200 series routers were not used in the network solution, the Cisco AS5300 access servers could not update routing tables, especially if 20 to 30 additional routers existed on the company’s backbone. Two additional backbone switches are used to provide access to the company network.

Note Depending on your networking needs, the Cisco 7200 series routers could be substituted by one or more Cisco 3640 series routers. Additionally, the Cisco AS5300 access servers could be replaced by Cisco 3640 routers loaded with MICA digital modem cards.

Figure 8 Sample Enterprise Network Topology

.)

Table 2 Options for Terminal Adapter Settings

Terminal Adapter Mode

Comments

Synchronous PPP

We recommend you use this mode for most terminal adapter scenarios. By default, Cisco access servers and routers have synchronous PPP enabled. Therefore, additional configuration is not required on the router or access server.

V.120

Use this mode for asynchronous to synchronous communication, which can be used to tunnel character mode sessions over synchronous ISDN. We recommend you use this mode with midrange routers, such as the Cisco 4500 series router.

V.110

Use this modem for setting up cellular modem access.

Mixed Protocol Dial-In Scenarios

The examples in the following sections are intended to run on each network device featured in Figure 8, which allows remote users to dial in to a mixed protocol environment:

- Cisco 7200 #1 Backbone Router

- Cisco 7200 #2 Backbone Router

- Cisco AS5300 Universal Access Server

Note Be sure to include your own IP addresses, host names, and security passwords where appropriate.

Cisco 7200 #1 Backbone Router

The following configuration runs on the router labeled Cisco 7200 #1 in Figure 8. Fast Ethernet interface 0/0 connects to the corporate backbone switch. Fast Ethernet interface 1/0 connects to the Catalyst 1900 switch, which in turn connects to the Cisco AS5300 access servers.

version xx.x

no service udp-small-servers

no service tcp-small-servers

!

hostname bbone-dial1

!

aaa new-model

aaa authentication login default local

aaa authentication login console enable

!

username admin password cisco

!

boot system flash slot0:

enable secret <password>

appletalk routing

ipx routing

!

interface FastEthernet0/0

ip address 10.0.1.52 255.255.255.192

appletalk cable-range 1000-1000

appletalk zone Networking Infrastructure

ipx network 1000

!

interface FastEthernet1/0

ip address 10.1.1.2 255.255.255.224

no ip redirects

appletalk cable-range 7650-7650 7650.1

appletalk zone Dial-Up Net

ipx network 7650

!

standby ip 10.1.1.1

standby priority 101

standby preempt

!

router eigrp 109

redistribute static

network 10.0.0.0

no auto-summary

!

ip classless

ip http server

no logging console

!

ip route 10.1.2.0 255.255.255.192 10.1.1.10

!

line con 0

login authentication console

!

line vty 0 4

login authentication default

end

Cisco 7200 #2 Backbone Router

The following configuration runs on the router labeled Cisco 7200 #2 in Figure 8. Fast Ethernet interface 0/0 connects to the corporate backbone switch. Fast Ethernet interface 1/0 connects to the Catalyst 1900 switch, which in turn connects to the Cisco AS5300 access servers.

version xx.x

no service udp-small-servers

no service tcp-small-servers

!

hostname bbone-dial2

!

aaa new-model

aaa authentication login default local

aaa authentication login console enable

!

username admin password cisco

!

boot system flash slot0:

enable secret <password>

appletalk routing

ipx routing

!

interface FastEthernet0/0

ip address 10.0.1.116 255.255.255.192

appletalk cable-range 1001-1001

appletalk zone Networking Infrastructure

ipx network 1001

!

interface FastEthernet1/0

ip address 10.1.1.3 255.255.255.224

no ip redirects

appletalk cable-range 7650-7650 7650.2

appletalk zone Dial-Up Net

ipx network 7650

!

standby ip 10.1.1.1

!

router eigrp 109

redistribute static

network 10.0.0.0

no auto-summary

!

ip classless

ip http server

no logging console

!

ip route 10.1.2.0 255.255.255.192 10.1.1.10

!

line con 0

login authentication console

!

line vty 0 4

login authentication console

!

end 4

Cisco AS5300 Universal Access Server

The following configuration runs on each Cisco AS5300 access server in the stack group shown in Figure 8:

version xx.x

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

no service udp-small-servers

no service tcp-small-servers

!

appletalk routing

ipx routing

appletalk virtual net 7651 Dial-Up Net

arap network 7652 Dial-Up Net

!

hostname NAS

!

aaa new-model

aaa authentication login default local

aaa authentication login console enable

aaa authentication login vty local

aaa authentication login dialin local

aaa authentication ppp default local

aaa authentication ppp dialin if-needed local

aaa authentication arap default auth-guest local

enable secret cisco

!

username admin password cisco

username pcuser1 password mypass

isdn switch-type primary-5ess

!

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

!

interface loopback 0

ip address 10.1.2.0 255.255.255.192

ipx network 7651

!

interface Ethernet0

ip address 10.1.1.10 255.255.255.0

appletalk cable-range 7650

appletalk zone Dial-Up-Net

ipx network 7650

!

interface Serial0

no ip address

shutdown

!

interface Serial1

no ip address

shutdown

!

interface Serial0:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Serial1:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Group-Async1

ip unnumbered Ethernet0

encapsulation ppp

async mode interactive

peer default ip address pool dialin_pool

appletalk client-mode

ipx ppp-client

no cdp enable

ppp authentication chap pap dialin

group-range 1 48

!

interface Dialer0

ip unnumbered Ethernet0

no ip mroute-cache

encapsulation ppp

peer default ip address pool dialin_pool

ipx ppp-client

appletalk client-mode

dialer in-band

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap pap dialin

ppp multilink

!

ip local pool dialin_pool 10.1.2.1 10.1.2.62

ip default-gateway 10.1.1.1

ip classless

ip route 0.0.0.0 0.0.0.0 10.1.1.1

!

dialer-list 1 protocol ip permit

!

async-bootp dns-server 10.1.0.40 10.1.0.170

async-bootp nbns-server 10.0.235.228 10.0.235.229

!

xremote buffersize 72000

xremote tftp host 10.0.2.74

!

line con 0

login authentication console

line 1 48

autoselect ppp

autoselect during-login

autoselect arap

arap enable

arap authentication default

arap timelimit 240

arap warningtime 15

login authentication dialin

modem DialIn

terminal-type dialup

line aux 0

login authentication console

line vty 0 4

login authentication vty

transport input telnet rlogin

!

end

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001–-2009 Cisco Systems, Inc. All rights reserved.

Telco and ISP Dial Scenarios and Configurations

This chapter provides sample hardware and software configurations for specific dial scenarios used by telcos, Internet service providers (ISPs), regional Bell operating companies (RBOCs), inter-exchange carriers (IXCs), and other service providers. Each configuration in this chapter is designed to enable IP network traffic with basic security authentication.

The following scenarios are described:

- Scenario 1—Small- to Medium-Scale POPs

- Scenario 2—Large-Scale POPs

- Scenario 3—PPP Calls over X.25 Networks

Note In all of these scenarios, you can replace the Cisco AS5200 access server with Cisco AS5300 or Cisco AS5800 access server. This hardware exchange provides higher call density performance and increases the number of PRI interfaces and modem ports on each chassis.

Small- to Medium-Scale POPs

Many small-to-medium-sized ISPs configure one or two access servers to provide dial-in access for their customers. Many of these dial-in customers use individual remote PCs that are not connected to LANs. Using the Windows 95 dialup software, remote clients initiate analog or digital connections using modems or home office ISDN BRI terminal adapters.

This section provides three types of single user dial-in scenarios for service providers:

- Individual Remote PCs Using Analog Modems

- Individual PCs Using ISDN Terminal Adapters

- Mixture of ISDN and Analog Modem Calls

Note Be sure to include your own IP addresses, host names, and security passwords where appropriate. The following sample configurations assume that the dial-in clients are individual PCs running PPP, connecting to an IP network, and requiring only basic security authentication.

Individual Remote PCs Using Analog Modems

ISPs can configure a single Cisco access servers to receive analog calls from remote PCs connected to modems, as shown in Figure 1. The point of presence (POP) at the ISP central site could also be a Cisco 2511 access server connected to external modems.

Network Topology

Figure 1 shows a small-scale dial-in scenario using modems.

Figure 1 Remote PC Using an Analog Modem to Dial In to a Cisco Access Server

Running Configuration for ISDN PRI

The following sample configuration runs on the Cisco access server, as shown in Figure 1, which enables remote analog users to dial in:

version xx.x

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

no service udp-small-servers

no service tcp-small-servers

!

hostname NAS

!

aaa new-model

aaa authentication login console enable

aaa authentication login vty tacacs+

aaa authentication login dialin tacacs+

aaa authentication ppp default tacacs+

aaa authentication ppp dialin if-needed tacacs+

enable secret cisco

!

async-bootp dns-server 10.1.3.1 10.1.3.2

isdn switch-type primary-5ess

!

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

!

interface Loopback0

ip address 10.1.2.254 255.255.255.0

!

interface Ethernet0

ip address 10.1.1.10 255.255.255.0

ip summary address eigrp 10 10.1.2.0 255.255.255.0

!

interface Serial0

no ip address

shutdown

!

interface Serial1

no ip address

shutdown

!

interface Serial0:23

no ip address

encapsulation ppp

isdn incoming-voice modem

!

interface Serial1:23

no ip address

isdn incoming-voice modem

!

interface Group-Async1

ip unnumbered Loopback0

encapsulation ppp

async mode interactive

peer default ip address pool dialin_pool

no cdp enable

ppp authentication chap pap dialin

group-range 1 48

!

router eigrp 10

network 10.0.0.0

passive-interface Dialer0

no auto-summary

!

ip local pool dialin_pool 10.1.2.1 10.1.2.50

ip default-gateway 10.1.1.1

ip classless

!

dialer-list 1 protocol ip permit

!

line con 0

login authentication console

line 1 48

autoselect ppp

autoselect during-login

login authentication dialin

modem DialIn

!

line aux 0

login authentication console

line vty 0 4

login authentication vty

transport input telnet rlogin

!

end

Some service providers use a remote TACACS+ or RADIUS security server in this dial-in scenario. The following example shows a TACACS+ entry that appears in the configuration file of a remote security server:

user = PCuser1 {

login = cleartext "dialpass1"

chap = cleartext "dialpass1"

service = ppp protocol = ip {

addr-pool = dialin_pool

}

service = exec {

autocmd = "ppp negotiate"

}

}

user = PCuser2 {

login = cleartext "dialpass2"

chap = cleartext "dialpass2"

service = ppp protocol = ip {

addr-pool = dialin_pool

}

service = exec {

autocmd = "ppp negotiate"

}

}

user = PCuser3 {

login = cleartext "dialpass3"

chap = cleartext "dialpass3"

service = ppp protocol = ip {

addr-pool = dialin_pool

}

service = exec {

autocmd = "ppp negotiate"

}

}

Running Configuration for Robbed-Bit Signaling

The following example shows a single Cisco access server configured to support remote client PCs dialing in with analog modems over traditional T1 lines. Digital ISDN calls do not transmit across these older types of channelized lines. The configuration assumes that the client can dial in and connect to the router in either terminal emulation mode (text only) or PPP packet mode.

Note The following configuration works only for analog modem calls. It includes no serial D-channel configuration (Serial 0:23 and Serial 1:23).

version xx.x

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

no service udp-small-servers

no service tcp-small-servers

!

hostname NAS

!

aaa new-model

aaa authentication login console enable

aaa authentication login vty tacacs+

aaa authentication login dialin tacacs+

aaa authentication ppp default tacacs+

aaa authentication ppp dialin if-needed tacacs+

enable secret cisco

!

async-bootp dns-server 10.1.3.1 10.1.3.2

isdn switch-type primary-5ess

!

controller T1 0

framing esf

clock source line primary

linecode b8zs

cas-group 0 timeslots 1-24 type e&m-fgb

!

controller T1 1

framing esf

clock source line secondary

linecode b8zs

cas-group 0 timeslots 1-24 type e&m-fgb

!

interface Loopback0

ip address 10.1.2.254 255.255.255.0

!

interface Ethernet0

ip address 10.1.1.10 255.255.255.0

ip summary address eigrp 10 10.1.2.0 255.255.255.0

!

interface Serial0

no ip address

shutdown

!

interface Serial1

no ip address

shutdown

!

interface Group-Async1

ip unnumbered Loopback0

encapsulation ppp

async mode interactive

peer default ip address pool dialin_pool

no cdp enable

ppp authentication chap pap dialin

group-range 1 48

!

router eigrp 10

network 10.0.0.0

passive-interface Dialer0

no auto-summary

!

ip local pool dialin_pool 10.1.2.1 10.1.2.50

ip default-gateway 10.1.1.1

ip classless

!

dialer-list 1 protocol ip permit

!

line con 0

login authentication console

line 1 48

autoselect ppp

autoselect during-login

login authentication dialin

modem DialIn

line aux 0

login authentication console

line vty 0 4

login authentication vty

transport input telnet rlogin

!

end

Individual PCs Using ISDN Terminal Adapters

ISPs can configure a single Cisco access server to receive digital multilink calls from remote PCs connected to terminal adapters, as shown in Figure 2. The POP at the central site of the ISP can be any Cisco router that supports ISDN PRI, such as the Cisco 4700-M router loaded with a channelized T1 PRI network module.

Network Topology

Figure 2 shows a small-scale dial-in scenario using terminal adapters.

Figure 2 Remote PC Using a Terminal Adapter to Dial In to a Cisco Access Server

To configure one Cisco access server to accept both incoming ISDN and analog calls from individual terminal adapters and modems, see the section “Mixture of ISDN and Analog Modem Calls” later in this chapter.

Terminal Adapter Configuration Example

The following example configures a Cisco access server to enable PCs fitted with internal or external terminal adapters to dial in to an IP network. The terminal adapter configuration is set up for asynchronous-to-synchronous PPP conversion. In some cases, PPP authentication must be set up for the Password Authentication Protocol (PAP). Some terminal adapters support only PAP authentication.

version xx.x

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

no service udp-small-servers

no service tcp-small-servers

!

hostname NAS

!

aaa new-model

aaa authentication login console enable

aaa authentication login vty tacacs+

aaa authentication login dialin tacacs+

aaa authentication ppp default tacacs+

aaa authentication ppp dialin if-needed tacacs+

enable secret cisco

!

async-bootp dns-server 10.1.3.1 10.1.3.2

isdn switch-type primary-5ess

!

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

!

interface Loopback0

ip address 10.1.2.254 255.255.255.0

!

interface Ethernet0

ip address 10.1.1.10 255.255.255.0

ip summary address eigrp 10 10.1.2.0 255.255.255.0

!

interface Serial0

no ip address

shutdown

!

interface Serial1

no ip address

shutdown

!

interface Serial0:23

no ip address

encapsulation ppp

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Serial1:23

no ip address

encapsulation ppp

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Dialer0

ip unnumbered Loopback0

no ip mroute-cache

encapsulation ppp

peer default ip address pool dialin_pool

dialer in-band

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap pap dialin

ppp multilink

!

router eigrp 10

network 10.0.0.0

passive-interface Dialer0

no auto-summary

!

ip local pool dialin_pool 10.1.2.1 10.1.2.50

ip default-gateway 10.1.1.1

ip classless

!

dialer-list 1 protocol ip permit

!

line con 0

login authentication console

line 1 48

autoselect ppp

autoselect during-login

login authentication dialin

modem DialIn

line aux 0

login authentication console

line vty 0 4

login authentication vty

transport input telnet rlogin

!

end

Mixture of ISDN and Analog Modem Calls

ISPs can configure a single Cisco access server to receive calls from a mixture of remote PCs connected to terminal adapters and modems, as shown in Figure 3.

Figure 3 Remote PCs Making Digital Calls and Analog Calls to a Cisco Access Server

Combination of Modem and ISDN Dial-In Configuration Example

The following example shows a combination of the modem and ISDN dial-in configurations. Using the bearer capability information element in the call setup packet, the incoming calls are labeled as data or voice. After the calls enter the access server, they are routed either to the serial configuration or to the modems and group asynchronous configuration.

Note This configuration assumes that only individual remote PCs are dialing in; no remote routers are dialing in. For a remote router dial-in configuration, see the chapter “Enterprise Dial Scenarios and Configurations” in this publication.

version xx.x

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

no service udp-small-servers

no service tcp-small-servers

!

hostname NAS

!

aaa new-model

aaa authentication login console enable

aaa authentication login vty tacacs+

aaa authentication login dialin tacacs+

aaa authentication ppp default tacacs+

aaa authentication ppp dialin if-needed tacacs+

enable secret cisco

!

async-bootp dns-server 10.1.3.1 10.1.3.2

isdn switch-type primary-5ess

!

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

!

interface Loopback0

ip address 10.1.2.254 255.255.255.0

!

interface Ethernet0

ip address 10.1.1.10 255.255.255.0

ip summary address eigrp 10 10.1.2.0 255.255.255.0

!

interface Serial0

no ip address

shutdown

!

interface Serial1

no ip address

shutdown

!

interface Serial0:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Serial1:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Group-Async1

ip unnumbered Loopback0

encapsulation ppp

async mode interactive

peer default ip address pool dialin_pool

no cdp enable

ppp authentication chap pap dialin

group-range 1 48

!

interface Dialer0

ip unnumbered Loopback0

no ip mroute-cache

encapsulation ppp

peer default ip address pool dialin_pool

dialer in-band

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap pap dialin

ppp multilink

!

router eigrp 10

network 10.0.0.0

passive-interface Dialer0

no auto-summary

!

ip local pool dialin_pool 10.1.2.1 10.1.2.50

ip default-gateway 10.1.1.1

ip classless

!

dialer-list 1 protocol ip permit

!

line con 0

login authentication console

line 1 48

autoselect ppp

autoselect during-login

login authentication dialin

modem DialIn

line aux 0

login authentication console

line vty 0 4

login authentication vty

transport input telnet rlogin

end

Large-Scale POPs

This section describes how to set up a stack of access servers for a large-scale dial solution and includes the following sections:

- Scaling Considerations

- How Stacking Works

- Stack Group of Access Servers Using MMP with an Offload Processor Examples

Scaling Considerations

Because of the significant increase in demand for Internet access, large POPs are required by many Telcos and ISPs. Internet access configurations can be set up to enable users who dial in with individual computers to make mixed ISDN multilink or modem connections using a stack of Cisco access servers that run Multichassis Multilink PPP (MMP).

.

Table 1 Recommended Configurations for Different Remote Access Needs

Dial-in Demand You Need to Support

Recommended Configuration

PCs dialing in, 75 to 90 percent modem calls, 10 to 25 percent ISDN calls (terminal adapters or routers), and support for fewer than 96 (T1) to 116 (E1) simultaneous dial-in connections.

Two Cisco access servers configured for IP, basic security, MMP, L2F, and no offload server.
Cisco IOS software.

PCs dialing in, less than 50 percent modem calls, more than 50 percent ISDN calls (terminal adapters or routers), dial-in only, and 250 or more simultaneous links into the offload server.

Three or more Cisco access servers configured for IP, remote security, MMP, and L2F. Each Cisco access server is configured to offload its segmentation and reassembly of the multilink sessions onto an offload server, such as a Cisco 7202 or Cisco 4700 router.
Cisco IOS software.

Note Depending on the size of your POP requirement, you can replace the Cisco AS5200 access server with a Cisco AS5300, Cisco AS5800, or Cisco AccessPath. This hardware exchange provides higher call density performance and increases the number of ISDN PRI ports, channelized ports, and modem ports on each chassis.

How Stacking Works

Before you install and configure a stack of access servers, you should understand the basic concepts described in the following sections and how they work together in a large-scale dial-in solution:

- A Typical Multilink PPP Session

- Using Multichassis Multilink PPP

- Setting Up an Offload Server

- Using the Stack Group Bidding Protocol

- Using L2F

A Typical Multilink PPP Session

A basic multilink session is an ISDN connection between two routing devices, such as a Cisco 766 router and a Cisco AS5200 access server. Figure 4 shows a remote PC connecting to a Cisco 766 ISDN router, which in turn opens two B-channel connections at 128 kbps across an ISDN network. The Multilink PPP (MLP) session is brought up. The Cisco 766 router sends four packets across the network to the Cisco AS5200, which in turn reassembles the packets back into the correct order and sends them out the LAN port to the Internet.

Figure 4 A Typical Multilink PPP Session

Using Multichassis Multilink PPP

Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.

The dial solution becomes more complex when the scenario is scaled to include multiple multilink calls connecting across multiple chassis. Figure 5 shows a terminal adapter making a call in to the Cisco AS5200, labeled #1. However, only one of the access server’s 48 B channels is available to accept the call. The other channels are busy with calls. As a result, one of the terminal adapter’s two B channels is redirected to device #2. At this point, a multilink multichassis session is shared between two Cisco AS5200s that belong to the same stack group. Packet fragments A and C go to device #1. Packet fragments B and D go to device #2.

Because device #1 is the first access server to receive a packet and establish a link, this access server creates a virtual interface and becomes the bundle master. The bundle master takes ownership of the MLP session with the remote device. The Multichassis Multilink PPP (MMP) protocol forwards the second link from device #2 to the bundle master, which in turn bundles the two B channels together and provides 128 kbps to the end user. Layer 2 Forwarding (L2F) is the mechanism that device #2 uses to forward all packet fragments received from the terminal adapter to device #1. In this way, all packets and calls virtually appear to terminate at device #1.

Figure 5 A Stack Group of Access Servers Using MMP Without an Offload Processor

Setting Up an Offload Server

Because MMP is a processor-intensive application, you might need to offload the processing or segmentation and reassembly from the Cisco access servers to a router with a more powerful CPU, such as the Cisco 4700-M or Cisco 7206. We recommend that you include an offload server for dial-in solutions that support more than 50 percent ISDN calls or more than 10 multilink sessions per Cisco access server. (See Figure 6.)

Figure 6 A Stack Group of Access Servers Using MMP with an Offload Processor

Using the Stack Group Bidding Protocol

The Stack Group Bidding Protocol (SGBP) is a critical component used in multichassis multilink sessions. SGBP unites each Cisco access server in a virtual stack, which enables the access servers to become virtually tied together. Each independent stack member communicates with the other members and determines which devices’ CPU should be in charge of running the multilink session and packet reassembly—the duty of the bundle master. The goal of SGBP is to find a common place to forward the links and ensure that this destination has enough CPU power to perform the segmentation and packet reassembly. (See Figure 6.)

When SGBP in configured on each Cisco access server, each access server sends out a query to each stack group member stating, for example, “I have a call coming in from walt@options.com. What is your bid for this user?” Each access server then consults the following default bidding criteria and answers the query accordingly:

- Do I have an existing call or link for the user walt@options.com? If I do, then bid very high to get this second link in to me.

- If I do not have an existing call for walt@options.com, then bid a value that is proportional to how much CPU power I have available.

- How busy am I supporting other users?

Note An offload server will always serve as the bundle master by bidding a higher value than the other devices.

Using L2F

Note Effective with Cisco Release 12.4(11)T, the L2F protocol was removed in Cisco IOS software.

L2F is a critical component used in multichassis multilink sessions. If an access server is not in charge of a multilink session, the access server encapsulates the fragmented PPP frames and forwards them to the bundle master using L2F. The master device receives the calls, not through the dial port (such as a dual T1/PRI card), but through the LAN or Ethernet port. L2F simply tunnels packet fragments to the device that owns the multilink session for the call. If you include an offload server in your dial-in scenario, it creates all the virtual interfaces, owns all the multilink sessions, and reassembles all the fragmented packets received by L2F via the other stackgroup members. (Refer to Figure 6.)

Stack Group of Access Servers Using MMP with an Offload Processor Examples

The following sections provide examples for the devices shown in Figure 6:

- Cisco Access Server #1

- Cisco Access Server #2

- Cisco Access Server #3

- Cisco 7206 as Offload Server

- RADIUS Remote Security Examples

Note Be sure to include your own IP addresses, host names, and security passwords where appropriate.

Cisco Access Server #1

The following configuration runs on the Cisco access server labeled #1 in Figure 6:

version xx.x

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

no service udp-small-servers

no service tcp-small-servers

!

hostname AS5200-1

!

aaa new-model

aaa authentication login default local

aaa authentication login console enable

aaa authentication login vty local

aaa authentication login dialin radius

aaa authentication ppp default local

aaa authentication ppp dialin if-needed radius

aaa authorization exec local radius

aaa authorization network radius

aaa accounting network start-stop radius

aaa accounting exec start-stop radius

enable secret cisco

!

username admin password cisco

username MYSTACK password STACK-SECRET

sgbp group MYSTACK

sgbp member AS5200-2 10.1.1.12

sgbp member AS5200-3 10.1.1.13

sgbp member 7200 10.1.1.14

async-bootp dns-server 10.1.3.1 10.1.3.2

isdn switch-type primary-5ess

!

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

!

interface Loopback0

ip address 10.1.2.62 255.255.255.192

!

interface Ethernet0

ip address 10.1.1.11 255.255.255.0

ip summary address eigrp 10 10.1.2.0 255.255.255.192

!

interface Serial0

no ip address

shutdown

!

interface Serial1

no ip address

shutdown

!

interface Serial0:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Serial1:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Group-Async1

ip unnumbered Loopback0

encapsulation ppp

async mode interactive

peer default ip address pool dialin_pool

no cdp enable

ppp authentication chap pap dialin

group-range 1 48

!

interface Dialer0

ip unnumbered Loopback0

no ip mroute-cache

encapsulation ppp

peer default ip address pool dialin_pool

dialer in-band

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap pap dialin

ppp multilink

!

router eigrp 10

network 10.0.0.0

passive-interface Dialer0

no auto-summary

!

ip local pool dialin_pool 10.1.2.1 10.1.2.50

ip default-gateway 10.1.1.1

ip classless

!

dialer-list 1 protocol ip permit

radius-server host 10.1.1.23 auth-port 1645 acct-port 1646

radius-server host 10.1.1.24 auth-port 1645 acct-port 1646

radius-server key cisco

!

line con 0

login authentication console

line 1 48

autoselect ppp

autoselect during-login

login authentication dialin

modem DialIn

line aux 0

login authentication console

line vty 0 4

login authentication vty

transport input telnet rlogin

!

end

Cisco Access Server #2

The following configuration runs on the Cisco access server labeled #2 shown in Figure 6:

version xx.x

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

no service udp-small-servers

no service tcp-small-servers

!

hostname AS5200-2

!

aaa new-model

aaa authentication login default local

aaa authentication login console enable

aaa authentication login vty local

aaa authentication login dialin radius

aaa authentication ppp default local

aaa authentication ppp dialin if-needed radius

aaa authorization exec local radius

aaa authorization network radius

aaa accounting network start-stop radius

aaa accounting exec start-stop radius

enable secret cisco

!

username admin password cisco

username MYSTACK password STACK-SECRET

sgbp group MYSTACK

sgbp member AS5200-1 10.1.1.11

sgbp member AS5200-3 10.1.1.13

sgbp member 7200 10.1.1.14

async-bootp dns-server 10.1.3.1 10.1.3.2

isdn switch-type primary-5ess

!

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

!

interface Loopback0

ip address 10.1.2.126 255.255.255.192

!

interface Ethernet0

ip address 10.1.1.12 255.255.255.0

ip summary address eigrp 10 10.1.2.64 255.255.255.192

!

interface Serial0

no ip address

shutdown

!

interface Serial1

no ip address

shutdown

!

interface Serial0:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Serial1:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Group-Async1

ip unnumbered Loopback0

encapsulation ppp

async mode interactive

peer default ip address pool dialin_pool

no cdp enable

ppp authentication chap pap dialin

group-range 1 48

!

interface Dialer0

ip unnumbered Loopback0

no ip mroute-cache

encapsulation ppp

peer default ip address pool dialin_pool

dialer in-band

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap pap dialin

ppp multilink

!

router eigrp 10

network 10.0..0.0

passive-interface Dialer0

no auto-summary

!

ip local pool dialin_pool 10.1.2.65 10.1.2.114

ip default-gateway 10.1.1.1

ip classless

!

dialer-list 1 protocol ip permit

radius-server host 10.1.1.23 auth-port 1645 acct-port 1646

radius-server host 10.1.1.24 auth-port 1645 acct-port 1646

radius-server key cisco

!

line con 0

login authentication console

line 1 48

autoselect ppp

autoselect during-login

login authentication dialin

modem DialIn

line aux 0

login authentication console

line vty 0 4

login authentication vty

transport input telnet rlogin

!

end

Cisco Access Server #3

The following configuration runs on the Cisco access server labeled #3 in Figure 6:

version xx.x

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

no service udp-small-servers

no service tcp-small-servers

!

hostname AS5200-3

!

aaa new-model

aaa authentication login default local

aaa authentication login console enable

aaa authentication login vty local

aaa authentication login dialin radius

aaa authentication ppp default local

aaa authentication ppp dialin if-needed radius

aaa authorization exec local radius

aaa authorization network radius

aaa accounting network start-stop radius

aaa accounting exec start-stop radius

enable secret cisco

!

username admin password cisco

username MYSTACK password STACK-SECRET

sgbp group MYSTACK

sgbp member AS5200-1 10.1.1.11

sgbp member AS5200-2 10.1.1.12

sgbp member 7200 10.1.1.14

async-bootp dns-server 10.1.3.1 10.1.3.2

isdn switch-type primary-5ess

!

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

!

interface Loopback0

ip address 10.1.2.190 255.255.255.192

!

interface Ethernet0

ip address 10.1.1.13 255.255.255.0

ip summary address eigrp 10 10.1.2.128 255.255.255.192

!

interface Serial0

no ip address

shutdown

!

interface Serial1

no ip address

shutdown

!

interface Serial0:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Serial1:23

no ip address

encapsulation ppp

isdn incoming-voice modem

dialer rotary-group 0

dialer-group 1

no fair-queue

no cdp enable

!

interface Group-Async1

ip unnumbered Loopback0

encapsulation ppp

async mode interactive

peer default ip address pool dialin_pool

no cdp enable

ppp authentication chap pap dialin

group-range 1 48

!

interface Dialer0

ip unnumbered Loopback0

no ip mroute-cache

encapsulation ppp

peer default ip address pool dialin_pool

dialer in-band

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap pap dialin

ppp multilink

!

router eigrp 10

network 10.0.0.0

passive-interface Dialer0

no auto-summary

!

ip local pool dialin_pool 10.1.2.129 10.1.2.178

ip default-gateway 10.1.1.1

ip classless

!

dialer-list 1 protocol ip permit

radius-server host 10.1.1.23 auth-port 1645 acct-port 1646

radius-server host 10.1.1.24 auth-port 1645 acct-port 1646

radius-server key cisco

!

line con 0

login authentication console

line 1 48

autoselect ppp

autoselect during-login

login authentication dialin

modem DialIn

line aux 0

login authentication console

line vty 0 4

login authentication vty

transport input telnet rlogin

!

end

Cisco 7206 as Offload Server

The following configuration runs on the Cisco 7206 router shown in Figure 6:

Note Any Cisco router that has a powerful CPU can be used as an offload server, such as a Cisco 4500-M, 4700-M, or 3640. However, the router must be configured to handle the necessary processing overhead demanded by each stack member.

version xx.x

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

no service udp-small-servers

no service tcp-small-servers

!

hostname 7200

!

aaa new-model

aaa authentication login default local

aaa authentication login console enable

aaa authentication login vty local

aaa authentication login dialin radius

aaa authentication ppp default local

aaa authentication ppp dialin if-needed radius

aaa authorization exec local radius

aaa authorization network radius

aaa accounting network start-stop radius

aaa accounting exec start-stop radius

enable secret cisco

!

username MYSTACK password STACK-SECRET

username admin password cisco

multilink virtual-template 1

sgbp group MYSTACK

sgbp member AS5200-1 10.1.1.11

sgbp member AS5200-2 10.1.1.12

sgbp member AS5200-3 10.1.1.13

sgbp seed-bid offload

async-bootp dns-server 10.1.3.1 10.1.3.2

!

interface Loopback0

ip address 10.1.2.254 255.255.255.192

!

interface Ethernet2/0

ip address 10.1.1.14 255.255.255.0

ip summary address eigrp 10 10.1.2.192 255.255.255.192

!

interface Ethernet2/1

no ip address

shutdown

!

interface Ethernet2/2

no ip address

shutdown

!

interface Ethernet2/3

no ip address

shutdown

!

interface Virtual-Template1

ip unnumbered Loopback0

no ip mroute-cache

peer default ip address pool dialin_pool

ppp authentication chap pap dialin

ppp multilink

!

router eigrp 10

network 10.0.0.0

passive-interface Virtual-Template1

no auto-summary

!

ip local pool dialin_pool 10.1.2.193 10.1.2.242

ip default-gateway 10.1.1.1

ip classless

!

radius-server host 10.1.1.23 auth-port 1645 acct-port 1646

radius-server host 10.1.1.24 auth-port 1645 acct-port 1646

radius-server key cisco

!

line con 0

login authentication console

line aux 0

login authentication console

line vty 0 4

login authentication vty

!

end

RADIUS Remote Security Examples

The RADIUS examples in the following sections use the Internet Engineering Task Force (IETF) syntax for the attributes:

- User Setup for PPP

- User Setup for PPP and Static IP Address

- Enabling Router Dial-In

- User Setup for SLIP

- User Setup for SLIP and Static IP Address

- Using Telnet to connect to a UNIX Host

- Automatic rlogin to UNIX Host

Depending on how the dictionary is set up, the syntax for these configurations might differ between versions of RADIUS daemons.

Note You must have the async dynamic address command enabled on the network access server if you use Framed-IP-Address to statically assign IP addresses.

User Setup for PPP

The following example shows a user setup for PPP. The user’s IP address comes from the configured default IP address that is set up on the interface (which could be a specific default IP address, a pointer to a local pool of addresses, or a pointer to a Dynamic Host Configuration Protocol (DHCP) server). The special address that signals the default address is 255.255.255.254.

pppme Password = "cisco"

CHAP-Password = "cisco"

Service-Type = Framed,

Framed-Protocol = PPP,

Framed-IP-Address = 255.255.255.254

User Setup for PPP and Static IP Address

The following example shows a user setup for PPP and a static IP address that stays with the user across all connections. Make sure that your router is set up to support this configuration, especially for large or multiple POPs.

staticallypppme Password = "cisco"

CHAP-Password = "cisco"

Service-Type = Framed,

Framed-Protocol = PPP,

Framed-IP-Address = 10.1.1.1

Enabling Router Dial-In

The following example supports a router dialing in, which requires that a static IP address and a remote Ethernet interface be added to the network access server’s routing table. The router’s WAN port is assigned the address 1.1.1.2. The remote Ethernet interface is 2.1.1.0 with a class C mask. Be sure your routing table can support this requirement. You might need to redistribute the static route with a dynamic routing protocol.

routeme Password = "cisco"

CHAP-Password = "cisco"

Service-Type = Framed,

Framed-Protocol = PPP,

Framed-IP-Address = 10.1.1.1

Framed-Route = "10.2.1.0/24 10.1.1.2"

User Setup for SLIP

The following example shows a user setup for SLIP. Remote users are assigned to the default address on the interface.

slipme Password = "cisco"

Service-Type = Framed,

Framed-Protocol = SLIP,

Framed-IP-Address = 255.255.255.254

User Setup for SLIP and Static IP Address

The following example shows a user setup for SLIP and a static IP address that stays with the user across all connections. Make sure that your routing is set up to support this configuration, especially for large or multiple POPs.

staticallyslipme Password = "cisco"

Service-Type = Framed,

Framed-Protocol = SLIP,

Framed-IP-Address = 10.1.1.13

Using Telnet to connect to a UNIX Host

The following example automatically uses Telnet to connect the user to a UNIX host. This configuration is useful for registering new users, providing basic UNIX shell services, or providing a guest account.

telnetme Password = "cisco"

Service-Type = Login,

Login-Service = Telnet,

Login-IP-Host = 10.2.1.1

Automatic rlogin to UNIX Host

The following example automatically uses rlogin to connect the user to a UNIX host:

rloginme Password = "cisco"

Service-Type = Login,

Login-Service = Rlogin,

Login-IP-Host =10.3.1.2

If you want to prevent a second password prompt from being brought up, you must have the following two commands enabled on the router or access server:

- rlogin trusted-remoteuser-source local

- rlogin trusted-localuser-source radius

PPP Calls over X.25 Networks

Remote PCs stationed in X.25 packet assembler-disassembler (PAD) networks can access the Internet by dialing in to Cisco routers, which support PPP. By positioning a Cisco router at the corner of an X.25 network, ISPs and telcos can provide Internet and PPP access to PAD users. All remote PAD users that dial in to X.25 networks dial in to one Cisco router that allows PPP connections. Although connection performance is not optimal, these X.25-to-PPP calls use installed bases of X.25 equipment and cost less to operate than connecting over the standard telephone network.

Note This dial-in scenario can also be used as an enterprise solution. In this case, an enterprise consults with a third-party service provider that allows enterprises to leverage existing X.25 enterprise equipment to provide connections back into enterprise environments.

Overview

Many cities throughout the world have large installed bases of PCs that interface with older modems, PADs, and X.25 networks. These remote PCs or terminals dial in to PADs and make X.25 PAD calls or terminal connections to mainframe computers or other devices, which run the X.25 protocol. Unfortunately, the user interface is only a regular text-based screen in character mode (as opposed to packet mode). Therefore, many ISPs and telcos that have large investments in X.25 networks are upgrading their outdated equipment and creating separate networks for PPP connections. Because this upgrade process takes substantial time and money to complete, using a Cisco router to allow PPP connections over an X.25 network is a good interim solution for a dead-end dial case.

Remote PC Browsing Network Topology

Figure 7 shows a remote PC browsing the Internet through an X.25 PAD call and a Cisco 4500 router. This X.25 network is owned by an ISP or telco that is heavily invested in X.25 equipment, that is currently upgrading its outdated equipment, and that is creating separate networks for PPP connections. In this topology, the Cisco 4500 router performs protocol translation between the protocols X.25 and PPP. The router is configured to accept an incoming X.25 PAD call, run and unpack PPP packets over the call, and enable the remote PC to function as if it were on the IP network.

Figure 7 Remote PC Browsing the Internet Through an X.25 PAD Call and a Cisco 4500 Router

.

Protocol Translation Configuration Example

In the following example, PAD callers that dial 4085551234 receive a router prompt. PAD callers that dial 4085555123401 start PPP and pick up an address from the IP pool called dialin_pool. These addresses are “borrowed” from the Ethernet interface on the Cisco 4500 router. Additionally, a loopback interface network can be created and the X.25 addresses can be set. However, a routing protocol must be run to advertise the loopback interface network if this method is used.

Note Be sure to include your own IP addresses, host names, and security passwords where appropriate in the following examples.

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

no service udp-small-servers

no service tcp-small-servers

!

hostname NAS

!

aaa new-model

aaa authentication login console enable

aaa authentication login vty tacacs+

aaa authentication login dialin tacacs+

aaa authentication ppp default tacacs+

aaa authentication ppp dialin if-needed tacacs+

enable secret cisco

!

async-bootp dns-server 10.1.3.1 10.1.3.2

!

vty-async

vty-async ppp authentication chap pap

!

interface Loopback0

ip address 10.1.2.254 255.255.255.0

!

interface Ethernet0

ip address 10.1.1.10 255.255.255.0

ip summary address eigrp 10 10.1.2.0 255.255.255.0

!

interface Serial0

no ip address

encapsulation x25

x25 address 4085551234

x25 accept-reverse

x25 default pad

!

router eigrp 10

network 10.0.0.0

passive-interface Dialer0

no auto-summary

!

ip local pool dialin_pool 10.1.2.1 10.1.2.50

ip default-gateway 10.1.1.1

!

ip classless

!

translate x25 4085555123401 ppp ip-pool scope-name dialin_pool

!

dialer-list 1 protocol ip permit

!

line con 0

login authentication console

line aux 0

login authentication console

line vty 0 150

login authentication vty

transport input telnet rlogin

!

end

x25 route 11111 interface Dialer0

x25 route 44444 interface Dialer0

!

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001–2009 Cisco Systems, Inc. All rights reserved.

Modem Initialization Strings

for a legend of symbols used in these two tables. Sample scripts follow the tables.

For information about configuring lines to support modems, see the chapters in the part “Modem and Dial Shelf Configuration and Management” in this publication.

Table 1 Required Settings and EC/Compression Settings

Settings Required for All Modems

Settings for EC/Compression

Modem

FD

AA

CD

DTR

RTS/CTS Flow

LOCK DTE Speed

Best Error

Best Comp

No Error

No Comp

Codex 3260

&F

S0=1

&C1

&D3

*FL3

*SC1

*SM3

*DC1

*SM1

*DC0

USR Sportster

&F

S0=1

&C1

&D3

&H1&R2

&B1

&M4

&K1

&M0

&K0

Teleport Gold

&F

S0=1

&C1

&D3

\Q3

\J0

\N7

%C1

\N0

%C0

T1600/T3000/WB

&F1

S0=1

&C1

&D3

S68=2

S51=6

S181=1

S190=1

S181=1

S190=0

T2500 (ECM)

&F

S0=1

&C1

&D3

S68=2

S51=6

S95=2

S96=1

S95=0

S96=0

Trailblazer

&F

S0=1

&C1

AT&T Paradyne Dataport

&F

S0=1

&C1

&D3

\Q3

--->

\N7

%C1

\N0

%C0

Optima

&F

S0=1

&C1

&D3

&K3

&Q6

&Q5

&Q9

&Q6

<---

QX4232 series

&F

S0=1

&C1

&D3

\Q3

\J0

\N6

%C1

\N0

%C0

FastTalk II

&F

S0=1

&C1

&D3

\Q3

\J0

\N6

%C1

\N0

%C0

MT1432 MT932

&F

S0=1

&C1

&D3

&E4

$BA0

&E1

&E15

&E0

&E14

Scout Plus

&F

S0=1

&C1

&D3

*F3

*S1

*E9

<---

*E0

<---

SoftModem

&F

S0=1

&C1

&D3

&K3

--->

\N5

%C1

\N0

%C0

14.4/9642c

&F

S0=1

&C1

&D3

&K3

--->

\N3

%M3

\N0

%M0

U-1496E

&F

S0=1

&C1

&D3

&H3

&B1

&K4

<---

&K0

<---

V.32bis/28.8

&F

S0=1

&C1

&D3

&K3

--->

\N3

%C1

\N0

%C0

14.4

&F

S0=1

&C1

&D3

&K3

--->

\N3

%C2

\N0

%C0

External

&F

S0=1

&C1

&D3

\Q3

\J0

\N3

%C1"H3

\N0

%C0

Peripherals

&F

S0=1

&C1

&D3

&K3

--->

&Q5

&Q9

&Q6

<---

Table 2 AUX and Platform Specific Settings

Modem

Settings for Use with AUX Port

Other Settings

Comments

No Echo

No Res

CAB-MDCE

Write Memory

Codex 3260

E0

Q1

&S1

&W

USR Sportster

E0

Q1

*NA*

&W

Teleport Gold

E0

Q1

*NA*

&W

T1600/T3000/WB

E0

Q1

&S4

&W

All Telebit modems need to have the speed set explicitly. These examples use 38400 bps. Using what Telebit calls “UNATTENDED ANSWER MODE” is the best place to start a dial in only modem.

T2500 (ECM)

E0

Q1

&S1

&W

Trailblazer

E0

Q1

*NA*

&W

Use “ENHANCED COMMAND MODE” on the T2500.

AT&T Paradyne Dataport

E0

Q1

*NA*

&W

Almost all Microcom modems have similar configuration parameters.

Optima

E0

Q1

*NA*

&W

QX4232 series

E0

Q1

*NA*

&W

FastTalk II

E0

Q1

*NA*

&W

MT1432 MT932

E0

Q1

&S1

&W

Scout Plus

E0

Q2

&B2

&W

SoftModem

E0

Q1

&S1

&W

14.4/9642c

E0

Q1

&S1

&W

U-1496E

E0

Q1

&S1

&W

Additional information on ftp.zyxel.com

V.32bis/28.8

E0

Q1

&S1

&W

14.4

E0

Q1

&S1

&W

External

E0

Q1

*NA*

&W

Peripherals

E0

Q1

*NA*

&W

Based on PC288LCD. May vary.

AUX and Platform Specific Settings.

Table 3 Legend to Symbols Used in Modem Chart

Symbol

Meaning

*NA*

This option is not available on the noted modem.

-->

The command noted on the right will handle that function.

<--

The command noted on the left will handle that function.

AUX port

These parameters are only required for pre-9.21 AUX ports or any other port without modem control set.

Sample Modem Scripts

command followed by a carriage return.

In the following example, the modem is attached to asynchronous interface 2 on the access server. The IP address indicated as the server-ip-address is the IP address of the Ethernet 0 interface. The administrator connects from the EXEC to asynchronous interface 2, which has its IP address assigned from Ethernet 0.

2511> telnet server-ip-address port-number

192.156.154.42 2002

AST Premium Exec Internal Data/Fax (MNP 5)

Init=AT&F&C1&D3\G0\J0\N3\Q2S7=60S0=1&W

Speed=9600

ATi 9600etc/e (V.42bis)

Init=AT&FW2&B1&C1&D3&K3&Q6&U1S7=60S0=1&W

Speed=38400

AT&T Paradyne KeepInTouch Card Modem (V.42bis)

Init=AT&FX6&C1&D3\N7\Q2%C1S7=60S0=1&w

Speed=57600

AT&T ComSphere 3800 Series (V.42bis)

Init=AT&FX6&C1&D2\N5\Q2%C1"H3S7=60S0=1&W

Speed=57600

AT&T DataPort Fax Modem (V.42bis)

Init=AT&FX6&C1&D2\N7\Q2%C1S7=60S0=1&W

Speed=38400

Boca Modem 14.4K/V.32bis (V.42bis)

Init=AT&FW2&C1&D3&K3&Q5%C1\N3S7=60S36=7S46=138S95=47S0=1&W

Speed=57600

CALPAK MXE-9600

Init=AT&F&C1&D3S7=60S0=1&W

Speed=9600

Cardinal 2450MNP (MNP 5)

Init=AT&F&C1&D3\J0\N3\Q2\V1%C1S7=60S0=1&w

Speed=9600

Cardinal 9650V32 (MNP)

Init=AT&F&B1&C1&D3&H1&I1&M6S7=60S0=1&W

Cardinal 9600V42 (V.42bis)

Init=AT&FW2&C1&D3&K3&Q5\N3%C1%M3S7=60S46=138S48=7S95=3S0=1&W

Speed=38400

Cardinal 14400 (V.42bis)

Init=AT&F&C1&D3&K3&Q5\N3%C1%M3S7=60S46=138S48=7S95=47S0=1&W

Speed=57600

COMPAQ SpeedPAQ 144 (V.42bis)

Init=AT&F&C1&D3&K3&Q5\J0\N3%C1S7=60S36=7S46=2S48=7S95=47S0=1&W

Speed=57600

Data Race RediMODEM V.32/V.32bis

Init=AT&F&C1&D3&K3&Q6\J0\N7\Q3\V2%C1S7=60 Speed=38400S0=1&W

Dell NX20 Modem/Fax (MNP)

Init=AT&F&C1&D3%C1\J0\N3\Q3\V1W2S7=60S0=1&W

Speed=9600

Digicom Systems (DSI) 9624LE/9624PC (MNP 5)

Init=AT&F&C1&D3*E1*F3*S1S7=60S0=1&W

Digicom Systems (DSI) 9624LE+ (V.42bis)

Init=AT&F&C1&D3*E9*F3*N6*S1S7=60S0=1&W

Speed=38400

Everex Evercom 24+ and 24E+ (MNP 5)

Init=AT&F&C1&D3\J0\N3\Q2\V1%C1S7=60S0=1&W

Everex EverFax 24/96 and 24/96E (MNP 5)

Init=AT&F&C1&D3\J0\N3\Q2\V1%C1S7=60S0=1&W

Speed=9600

Everex Evercom 96+ and 96E+ (V.42bis)

Init=AT&FW2&C1&D3\J0\N3\Q2\V2%C1S7=60S0=1&W

Speed=38400

Data/FAX Modem

Init=AT&F&C1&D3&K3&Q6\J0\N7\Q3\V2%C1S7=60S0=1&W

Speed=38400

Gateway 2000 TelePath

Init=AT&FW2&C1&D3&K3&Q5\N3%C1S7=60S36=7S46=138S48=7S95=47S0=1&W

Speed=38400

Gateway 2000 Nomad 9600 BPS Internal Modem

Init=AT&F&C1&D3%C1\J0\N3\Q2S7=60S0=1&W

Speed=38400

GVC SM-96V (V.42bis)

Init=AT&F&C1&D3%C1\J0\N6\Q2\V1S7=60S0=1&W

Speed=38400

GVC SM-144V (V.42bis)

Init=AT&F&C1&D3%C1\J0\N6\Q2\V1S7=60S0=1&W

Speed=57600

Hayes Smartmodem Optima 9600 (V.42bis)

Init=AT&FW2&C1&D3&K3&Q5S7=60S46=138S48=7S95=47S0=1&W

Speed=38400

Hayes Smartmodem Optima 14400 (V.42bis)

Init=AT&FW2&C1&D3&K3&Q5S7=60S46=138S48=7S95=47S0=1&W

Speed=57600

Hayes Optima 28800 (V.34)

Init=AT&FS0=1&C1&D3&K3&Q6&Q5&Q9&W

Speed=115200

Hayes V-series Smartmodem 9600/9600B (V.42)

Init=AT&F&C1&D3&K3&Q5S7=60S0=1&W

Speed=9600

Hayes V-series ULTRA Smartmodem 9600 (V.42bis)

Init=AT&F&C1&D3&K3&Q5S7=60S46=2S48=7S95=63S0=1&W

Speed=38400

Hayes V-series ULTRA Smartmodem 14400 (V.42bis)

Init=AT&FW2&C1&D3&K3&Q5S7=60S38=10S46=2S48=7S95=63S0=1&W

Speed=38400

Hayes ACCURA 24 EC (V.42bis)

Init=AT&FW2&C1&D3&K3&Q5S7=60S36=7S46=138S48=7S95=47S0=1&W

Hayes ACCURA 96 EC (V.42bis)

Init=AT&FW2&C1&D3&K3&Q5S7=60S36=7S46=138S48=7S95=47S0=1&W

Speed=38400

Hayes ACCURA 144 EC (V.42bis)

Init=AT&FW2&C1&D3&K3&Q5S7=60S36=7S46=138S48=7S95=47S0=1&W

Speed=57600

Hayes ISDN System Adapter

Init=AT&FW1&C1&D3&K3&Q0S7=60S0=1&W

Speed=57600

IBM 7855 Modem Model 10 (MNP)

Init=AT&F&C1&D3\N3\Q2\V1%C1S7=60S0=1&W

IBM Data/Fax Modem PCMCIA (V.42bis)

Init=AT&F&C1&D3&K3&Q5%C3\N3S7=60S38=7S46=138S48=7S95=47S0=1&W

Speed=57600

Identity ID9632E

Init=AT&F&C1&D3S7=60S0=1&W

Speed=9600

Infotel V.42X (V.42bis)

Init=AT&F&C1&D3S7=30S36=7S0=1&W

Speed=9600

Infotel V.32 turbo (V.42bis)

Init=AT&FW1&C1&D3&K3&Q5S7=60S0=1&w

Speed=38400

Infotel 144I (V.42bis)

Init=AT&F&C1&D3&K3&Q5\N3%C1S7=60S36=7S46=138S48=7S95=47S0=1&W

Speed=38400

Intel 9600 EX (V.42bis)

Init=AT&F&C1&D3\J0\N3\Q2\V2%C1"H3S7=60S0=1&W

Speed=38400

Intel 14400 EX (V.42bis)

Init=AT&F&C1&D3\J0\N3\Q2\V2%C1"H3S7=60S0=1&W

Speed=38400

Macronix MaxFax 9624LT-S

Init=AT&F&C1&D3&K3&Q9\J0\N3\Q3%C1S7=60S36=7S46=138S48=7S95=47S0=1&W

Speed=9600

Megahertz T3144 internal (V.42bis)

Init=AT&F&C1&D3%C1\J0\N3\Q2\V2S7=60S0=1&W

Speed=57600

Megahertz T324FM internal (V.42bis)

Init=AT&F&C1&D3%C1\J0\N3\Q2\V1S7=60S46=138S48=7S0=1&W

Speed=9600

Megahertz P2144 FAX/Modem (V.42bis)

Init=AT&F&C1&D3%C1\J0\N7\Q2\V2S7=60S0=1&W

Speed=38400

Megahertz T396FM internal (V.42bis)

Init=AT&FW2&C1&D3%C1\J0\N7\Q2\V2S7=60S0=1&W

Speed=38400

Megahertz CC3144 PCMCIA card modem (V.42bis)

Init=AT&F&C1&D3&K3&Q5%C3\N3S7=60S38=7S46=138S48=7S95=47S0=1&W

Speed=57600

Microcom AX/9624c (MNP 5)

Init=AT&F&C1&D3\G0\J0\N3\Q2%C1S7=60S0=1&W

Speed=9600

Microcom AX/9600 Plus (MNP 5)

Init=AT&F&C1&D3\J0\N3\Q2S7=60S0=1&W

Microcom QX/V.32c (MNP 5)

Init=AT&F&C1&D3\J0%C3\N3\Q2S7=60S0=1&W

Speed=38400

Microcom QX/4232hs (V.42bis)

Init=AT&F&C1&D3\J0%C3\N3\Q2-K0\V2S7=60S0=1&W

Speed=38400

(V.42bis)

Init=AT&F&C1&D3\J0%C3\N3\Q2-K0\V2W2S7=60S0=1&W

Speed=38400

Microcom Deskporte 28800 (V.34)

Init=AT&F&c1&q1E0S0=1&W

Speed=115200

Microcom MicroPorte 542 (V.42bis)

Init=AT&F&C1&D3&Q5S7=60S46=138S48=7S95=47S0=1&W

Speed=9600

Microcom MicroPorte 1042 (V.42bis)

Init=AT&F&C1&D3%C3\J0-M0\N6\Q2\V2S7=60S0=1&W

Speed=9600

(V.42bis)

Init=AT&F&C1&D3%C3%G0\J0-M0\N6\Q2\V2S7=60S0=1&W

Speed=38400

Microcom DeskPorte FAST

Init=ATX4S7=60-M1\V4\N2L1S0=1&W

Speed=57600

Motorola/Codex 3220 (MNP)

Init=AT&F&C1&D3*DC1*FL3*MF0*SM3*XC2S7=60S0=1&W

Motorola/Codex 3220 Plus (V.42bis)

Init=AT&F&C1&D3*DC1*EC0*MF0*SM3*XC2S7=60S0=1&W

Speed=38400

Motorola/Codex 326X Series (V.42bis)

Init=AT&F&C1&D3*FL3*MF0*SM3*TT2*XC2S7=60S0=1&W

Speed=38400

MultiTech MultiModem V32EC (V.42bis)

Init=AT&FX4&C1&D3$BA0&E1&E4&E15#L0S7=60S0=1&W

Speed=38400

MultiTech MultiModem V32 (no MNP or V.42)

Init=AT&F&C1&D3S7=60S0=1&W

Speed=9600

MultiTech MultiModem 696E (MNP)

Init=AT&F&C1&D3$BA0&E1&E4&E15S7=60S0=1&W

MultiTech MultiModem II MT932 (V.42bis)

Init=AT&FX4&C1&D3$BA0&E1&E4&E15#L0S7=60S0=1&W

Speed=38400

MultiTech MultiModem II MT1432 (V.42bis)

Init=AT&FX4&C1&D3#A0$BA0&E1&E4&E15#L0S7=60S0=1&W

Speed=57600

NEC UltraLite 14.4 Data/Fax Modem (V.42bis)

Init=AT&F&C1&D3&K3&Q4\J0\N7\Q2W2%C1S7=60S0=1&W

Speed=38400

Practical Peripherals PC28800SA (V.42bis)

Init=AT&F&C1&D3&K3&Q5S7=60S36=7S46=2S48=7S95=47S0=1&W

Speed=115200

Practical Peripherals PM9600SA (V.42bis)

Init=AT&F&C1&D3&K3&Q5S46=138S48=7S7=60S0=1&W

Speed=38400

Practical Peripherals PM14400FX (V.42bis)

Init=AT&F&C1&D3&K3&Q5S7=60S36=7S46=2S48=7S95=47S0=1&W

Speed=57600

Practical Peripherals PM14400SA (V.42bis)

Init=AT&F&C1&D3&K3&Q5S7=60S36=7S46=2S48=7S95=47S0=1&W

Speed=57600

Prometheus ProModem 9600 Plus (V.42)

Init=AT&F&C1&D3*E7*F3S7=60S0=1&W

Prometheus ProModem Ultima (V.42bis)

Init=AT&F&C1&D3*E9*F3*N6*S1S7=60S0=1&W

Speed=38400

Racal Datacomm ALM 3223 (V.42bis)

Init=AT&F&C1&D3\M0\N3\P2\Q1\V1S7=60S0=1&W

Speed=38400

(V.42bis)

Init=AT&FN1W2&C1&D1&K3&Q5\N3%C1S7=60S36=7S48=7S95=45S0=1&W

Speed=57600

Telebit T1600 (V.42bis)

Init=AT&FX2&C1&D3&R3S7=60S51=6S58=0S59=15S68=2S180=2S190=1S0=1&W

Speed=38400

Telebit T2500 (V.42bis)

Init=AT~&FX2S7=60S51=5S52=2S66=1S68=2S97=1S98=3S106=1S131=1S0=1&W

Telebit T3000 (V.42bis)

Init=AT&FX2&C1&D3S51=6S59=7S68=2S7=60S0=1&W

Speed=38400

Telebit QBlazer (V.42bis)

Init=AT&FX2&C1&D3S59=7S68=2S7=60S0=1&W

Speed=38400

Internal Modem

Init=AT&F&C1&D3%C1\J0\N7\Q2\V2S7=60S0=1&W

Speed=38400

Toshiba T24/DF Internal

Init=AT&F&C1&D3\J0\N3\Q2%C1S7=60S36=7S46=138S48=7S0=1&W

Speed=9600

Universal Data Systems FasTalk V.32/42b (V.42bis)

Init=AT&F&C1&D3\J0\M0\N7\V1\Q2%C1S7=60S0=1&W

Speed=38400

Universal Data Systems V.32 (no MNP or V.42)

Init=AT&F&C1&D2S7=60S0=1&W

Speed=9600

Universal Data Systems V.3224 (MNP 4)

Init=AT&F&C1&D2\J0\N3\Q2S7=60S0=1&W

Universal Data Systems V.3225 (MNP 5)

Init=AT&F&C1&D2\J0\N3\Q2%C1S7=60S0=1&W

Universal Data Systems V.3227 (V.42bis)

Init=AT&F&C1&D2\J0\M0\N7\Q2%C1S7=60S0=1&W

Speed=38400

Universal Data Systems V.3229 (V.42bis)

Init=AT&F&C1&D3\J0\M0\N7\Q2%C1S7=60S0=1&W

Speed=38400

US Robotics Sportster 9600 (V.42bis)

Init=AT&FX4&A3&B1&D3&H1&I0&K1&M4S7=60S0=1&W

Speed=38400

US Robotics Sportster 14400 (V.42bis)

Init=AT&FX4&A3&B1&D3&H1&I0&K1&M4S7=60S0=1&W

Speed=57600

US Robotics Sportster 14400 (V.42bis) x

Init=AT&FX4&B1&C1&D2&H1&K1&M4E0X7Q0V1S0=1&W

Speed=57600

US Robotics Sportster 28800 (V.34)

Init=AT&FS0=1&C1&D2&H1&R2&N14&B1&W

Speed=115200

US Robotics Courier 28800 (V.34)

Init=AT&FS0=1&C1&D2&H1&R2&N14&B1&W

Speed=115200

US Robotics Courier V.32bis (V.42bis)

Init=AT&FX4&A3&C1&D2&M4&H1&K1&B1S0=1&W

Speed=38400

US Robotics Courier HST Dual Standard (V.42bis)

Init=AT&FB0X4&A3&C1&D2&M4&H1&K1&B1&R2&S1S0=1&W

Speed=115200

US Robotics Courier HST (V.42bis)

Init=AT&FB0X4&A3&C1&D2&M1&H1&K1&B1S0=1&W

Speed=115200

US Robotics WorldPort 2496 FAX/Data (V.42bis)

Init=AT&FX4&C1&D3%C1"H3\J0-J1\N3\Q2\V2S7=60S0=1&W

Speed=57600

US Robotics WorldPort 9696 FAX/Data (MNP 5)

Init=AT&FX4&C1&D3%C1\J0\N3\Q2\V2S7=60S0=1&W

US Robotics WorldPort 9600 (MNP 5)

Init=AT&FX4&C1&D3%C1\J0\N3\Q2\V2S7=60S0=1&W

US Robotics WorldPort 14400 (V.42bis)

Init=AT&FX4&A3&B1&C1&D3&H1&K1&M4S7=60S0=1&W

Speed=57600

Ven-Tel PCM 9600 Plus (MNP)

Init=AT&FB0&C1&D3\N3\Q3%B0%C1%F1S7=60S0=1&W

ViVa 9642e (V.42bis)

Init=AT&F&C1&D3&K3&Q5\N3%C3S7=60S36=7S46=138S48=7S95=47S0=1&W

Speed=38400

ViVa 14.4/FAX (V.42bis)

Init=AT&F&C1&D3&K3&Q5\N3%C3S7=60S36=7S46=138S48=7S95=47S0=1&W

Speed=38400

ZOOM V.32 turbo (V.42bis)

Init=AT&FW1&C1&D3&K3&Q5%C1\N3S7=60S36=7S46=138S48=7S95=47S0=1&W

Speed=38400

(V.42bis)

Init=AT&FW1&C1&D3&K3&Q9%C1\N3S7=60S36=7S95=47S0=1&W

Speed=38400

Zyxel U-1496 (V.42bis)

Init=AT&FX6&B1&C1&D2&N0&K4&H3S7=60S0=1&W

Speed=57600

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2001–2009 Cisco Systems, Inc. All rights reserved.

Overview of Dial Interfaces, Controllers, and Lines

This chapter describes the different types of software constructs, interfaces, controllers, channels, and lines that are used for dial-up remote access. It includes the following main sections:

- Cisco IOS Dial Components

- Logical Constructs

- Logical Interfaces

- Circuit-Switched Digital Calls

- T1 and E1 Controllers

- Non-ISDN Channelized T1 and Channelized E1 Lines

- ISDN Service

- Line Types

- Encapsulation Types

. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

Cisco IOS Dial Components

Different components inside Cisco IOS software work together to enable remote clients to dial in and send packets. Figure 1 shows one Cisco AS5300 access server that is receiving calls from a remote office, branch office (ROBO); small office, home office (SOHO); and modem client.

Depending on your network scenario, you may encounter all of the components in Figure 1. For example, you might decide to create a virtual IP subnet by using a loopback interface. This step saves address space. Virtual subnets can exist inside devices that you advertise to your backbone. In turn, IP packets get relayed to remote PCs, which route back to the central site.

Figure 1 Cisco IOS Dial Universe

Logical Constructs

A logical construct stores core protocol characteristics to assign to physical interfaces. No data packets are forwarded to a logical construct. Cisco uses three types of logical constructs in its access servers and routers. These constructs are described in the following sections:

- Asynchronous Interfaces

- Group Asynchronous Interfaces

- Virtual Template Interfaces

Asynchronous Interfaces

An asynchronous interface assigns network protocol characteristics to remote asynchronous clients that are dialing in through physical terminal lines and modems. (See Figure 2.)

command to create and configure an asynchronous interface.

Figure 2 Logical Construct for an Asynchronous Interface

To enable clients to dial in, you must configure two asynchronous components: asynchronous lines and asynchronous interfaces. Asynchronous interfaces correspond to physical terminal lines. For example, asynchronous interface 1 corresponds to tty line 1.

Commands entered in asynchronous interface mode configure protocol-specific parameters for asynchronous interfaces, whereas commands entered in line configuration configure the physical aspects for the same port.

Specifically, you configure asynchronous interfaces to support PPP connections. An asynchronous interface on an access server or router can be configured to support the following functions:

- Network protocol support such as IP, Internet Protocol Exchange (IPX), or AppleTalk

- Encapsulation support (such as PPP)

- IP client addressing options (default or dynamic)

- IPX network addressing options

- PPP authentication

- ISDN BRI and PRI configuration

Group Asynchronous Interfaces

A group asynchronous interface is a parent interface that stores core protocol characteristics and projects them to a specified range of asynchronous interfaces. Asynchronous interfaces clone protocol information from group asynchronous interfaces. No data packets arrive in a group asynchronous interface. By setting up a group asynchronous interface, you also eliminate the need to repeatedly configure identical configuration information across several asynchronous interfaces.

Virtual Template Interfaces

A virtual template interface stores protocol configuration information for virtual access interfaces and protocol translation sessions. (See Figure 3.)

Figure 3 Logical Construct for a Virtual Template Interface

Templates for Virtual Access Interfaces

Virtual templates project configuration information to temporary virtual access interfaces triggered by multilink or virtual private dial-up network (VPDN) session events. When a virtual access interface is triggered, the configuration attributes in the virtual template are cloned and the negotiated parameters are applied to the connection.

The following example shows a virtual template interface on a Cisco 7206 router, which is used as a home gateway in a VPDN scenario:

Router# configure terminal

Router(config)# interface virtual-template 1

Router(config-if)# ip unnumbered ethernet 2/1

Router(config-if)# peer default ip address pool cisco-pool

Router(config-if)# ppp authentication chap pap

Router(config-if)# exit

Router(config)# vpdn enable

Router(config)# vpdn incoming isp cisco.com virtual-template 1

Templates for Protocol Translation

. This virtual access interface is a temporary interface that supports the protocol configuration specified in the virtual interface template. This virtual access interface is created dynamically and lasts only as long as the tunnel session is active.

The virtual template in the following example explicitly specifies PPP encapsulation. The translation is from X.25 to PPP, which enables tunneling of PPP across an X.25 network.

Router# configure terminal

Router(config)# interface virtual-template 1

Router(config-if)# ip unnumbered ethernet 0

Router(config-if)# peer default ip address 172.18.2.131

Router(config-if)# encapsulation ppp

Router(config-if)# exit

Router(config)# translate x25 5555678 virtual-template 1

.

Logical Interfaces

A logical interface receives and sends data packets and controls physical interfaces. Cisco IOS software provides three logical interfaces used for dial access. These interfaces are described in the following sections:

- Dialer Interfaces

- Virtual Access Interfaces

- Virtual Asynchronous Interfaces

Dialer Interfaces

A dialer interface is a parent interface that stores and projects protocol configuration information that is common to all data (D) channels that are members of a dialer rotary group. Data packets pass through dialer interfaces, which in turn initiate dialing for inbound calls. In most cases, D channels get their core protocol intelligence from dialer interfaces.

Figure 4 shows packets coming into a dialer interface, which contains the configuration parameters common to four D channels (shown as S0:0, S0:1, S0:2, and S0:3). All the D channels are members of the same rotary group. Without the dialer interface configuration, each D channel must be manually configured with identical properties. Dialer interfaces condense and streamline the configuration process.

Figure 4 Dialer Interface and Its Neighboring Components

global configuration command.

The following example shows a fully configured dialer interface:

Router# configure terminal

Router(config)# interface dialer 0

Router(config-if)# ip unnumbered loopback 0

Router(config-if)# no ip mroute-cache

Router(config-if)# encapsulation ppp

Router(config-if)# peer default ip address pool dialin_pool

Router(config-if)# dialer in-band

Router(config-if)# dialer-group 1

Router(config-if)# no fair-queue

Router(config-if)# no cdp enable

Router(config-if)# ppp authentication chap pap callin

Router(config-if)# ppp multilink

All the D channels are members of rotary group 1.

Virtual Access Interfaces

A virtual access interface is a temporary interface that is spawned to terminate incoming PPP streams that have no physical connections. PPP streams, Layer 2 Forwarding Protocol (L2F), and Layer 2 Tunnel Protocol (L2TP) frames that come in on multiple B channels are reassembled on virtual access interfaces. These access interfaces are constructs used to terminate packets.

Virtual access interfaces obtain their set of instructions from virtual interface templates. The attributes configured in virtual templates are projected or cloned to a virtual access interfaces. Virtual access interfaces are not directly user configurable. These interfaces are created dynamically and last only as long as the tunnels or multilink sessions are active. After the sessions end, the virtual access interfaces disappear.

Figure 5 shows how a virtual access interface functions to accommodate a multilink session event. Two physical interfaces on two different access servers are participating in one multilink call from a remote PC. However, each Cisco AS5300 access server has only one B channel available to receive a call. All other channels are busy. Therefore all four packets are equally dispersed across two separate B channels and two access servers. Each Cisco AS5300 access server receives only half the total packets. A virtual access interface is dynamically spawned upstream on a Cisco 7206 backhaul router to receive the multilink protocol, track the multilink frames, and reassemble the packets. The Cisco 7206 router is configured to be the bundle master, which performs all packet assembly and reassembly for both Cisco AS5300 access servers.

Figure 5 Virtual Access Interfaces Used for Multichassis Multilink Session Events

Virtual Asynchronous Interfaces

A virtual asynchronous interface is created on demand to support calls that enter the router through a nonphysical interface. For example, asynchronous character stream calls terminate or land on nonphysical interfaces. These types of calls include inbound Telnet, LAT, PPP over character-oriented protocols (such as V.120 or X.25), and LAPB-TA and PAD calls. A virtual asynchronous interface is also used to terminate L2F/L2TP tunnels, which are often traveling companions with Multilink protocol sessions. Virtual asynchronous interfaces are not user configurable; rather, they are dynamically created and torn down on demand. A virtual asynchronous line is used to access a virtual asynchronous interface.

Figure 6 shows a variety of calls that are terminating on a virtual asynchronous interface. After the calls end, the interface is torn down.

Figure 6 Asynchronous Character Stream Calls Terminating on a Virtual Asynchronous Interface

Circuit-Switched Digital Calls

Circuit-switched digital calls are usually ISDN 56-kbps or 64-kbps data calls that use PPP. These calls are initiated by an ISDN router, access server, or terminal adapter that is connected to a client workstation. Individual synchronous serial digital signal level 0 (DS0) bearer (B) channels are used to transport circuit-switched digital calls across WANs. These calls do not transmit across “old world” lines.

Figure 7 shows a Cisco 1600 series remote office router dialing in to a Cisco 3640 router positioned at a headquarters gateway.

Figure 7 Remote Office LAN Dialing In to Headquarters

T1 and E1 Controllers

Cisco controllers negotiate the following parameters between an access server and a central office: line coding, framing, clocking, DS0/time-slot provisioning, and signaling.

command. Most telephone companies do not support provisioning one trunk for different combinations of time-slot services, though this provisioning is supported on Cisco controllers. On a T1 controller, for example, time slots 1 to 10 could run PRI, time slots 11 to 20 could run channel-associated signaling (CAS), and time slots 21 to 24 could support leased-line grouping.

The following example configures one of four T1 controllers on a Cisco AS5300 access server:

Router# configure terminal

Router(config)# controller t1 ?

<0-3> Controller unit number

Router(config)# controller t1 0

Router(config-controller)# framing esf

Router(config-controller)# linecode b8zs

Router(config-controller)# clock source line primary

Router(config-controller)# pri-group timeslots 1-24

Router(config-controller)#

This example supports modem calls and circuit-switched digital calls over ISDN PRI.

Non-ISDN Channelized T1 and Channelized E1 Lines

A channelized T1 or channelized E1 line is an analog line that was originally intended to support analog voice calls, but has evolved to support analog data calls. ISDN is not sent across channelized T1 or E1 lines. Channelized T1 and channelized E1 lines are often referred to as CT1 and CE1. These channelized lines are found in “old world,” non-ISDN telephone networks.

The difference between traditional channelized lines (analog) and nonchannelized lines (ISDN) is that channelized lines have no built-in D channel. That is, all 24 channels on a T1 line carry only data. The signaling is in-band or associated to the data channels. Traditional channelized lines do not support digitized data calls (for example, BRI with 2B + D). Channelized lines support a variety of in-band signal types, such as ground start, loop start, wink start, immediate start, E&M, and R2.

controller configuration command. The following example configures E&M group B signaling on a T1 controller:

Router# configure terminal

Router(config)# controller t1 0

Router(config-controller)# cas-group 1 timeslots 1-24 type ?

e&m-fgb E & M Type II FGB

e&m-fgd E & M Type II FGD

e&m-immediate-start E & M Immediate Start

fxs-ground-start FXS Ground Start

fxs-loop-start FXS Loop Start

r1-modified R1 Modified

sas-ground-start SAS Ground Start

sas-loop-start SAS Loop Start

Router(config-controller)# cas-group 1 timeslots 1-24 type e&m-fgb

Router(config-controller)# framing esf

Router(config-controller)# clock source line primary

ISDN Service

Cisco routing devices support ISDN BRI and ISDN PRI. Both media types use B channels and D channels. Figure 8 shows how many B channels and D channels are assigned to each media type.

Figure 8 Logical Relationship of B Channels and D Channels

ISDN BRI

ISDN BRI operates over most of the copper twisted-pair telephone wiring in place. ISDN BRI delivers a total bandwidth of a 144 kbps via three separate channels. Two of the B channels operate at 64 kbps and are used to carry voice, video, or data traffic. The third channel, the D channel, is a 16-kbps signaling channel used to tell the Public Switched Telephone Network (PSTN) how to handle each of the B channels. ISDN BRI is often referred to as “2 B + D.”

command to bring up and configure a single BRI interface, which is the overseer of the 2 B + D channels. The D channel is not user configurable.

command defines the service profile identifier (SPID) number for both B channels. The SPID number is assigned by the ISDN service provider. Not all ISDN lines have SPIDs.

Router# configure terminal

Router(config)# interface bri 0

Router(config-if)# isdn spid1 55598760101

Router(config-if)# isdn spid2 55598770101

Router(config-if)# isdn switch-type basic-ni

Router(config-if)# ip unnumbered ethernet 0

Router(config-if)# dialer map ip 172.168.37.40 name hq 5552053

Router(config-if)# dialer load-threshold 70

Router(config-if)# dialer-group 1

Router(config-if)# encapsulation ppp

Router(config-if)# ppp authentication chap pap callin

Router(config-if)# ppp multilink

Router(config-if)# no shutdown

ISDN PRI

ISDN PRI is designed to carry large numbers of incoming ISDN calls at point of presences (POPs) and other large central site locations. All the reliability and performance of ISDN BRI applies to ISDN PRI, but ISDN PRI has 23 B channels running at 64 kbps each and a shared 64 kbps D channel that carries signaling traffic. ISDN PRI is often referred to as “23 B + D” (North America and Japan) or “30 B + D” (rest of the world).

command to bring up and configure the D channel, which is user configurable.

Figure 9 shows the logical contents of an ISDN PRI interface used in a T1 network configuration. The logical contents include 23 B channels, 1 D channel, 24 time slots, and 24 virtual serial interfaces (total number of B + D channels).

Figure 9 Logical Relationship of ISDN PRI Components for T1

The following example is for a Cisco AS5300 access server. It configures one T1 controller for ISDN PRI, then configures the neighboring D channel (interface serial 0:23). Controller T1 0 and interface serial 0:23 are both assigned to the first PRI port. The second PRI port is assigned to controller T1 1 and interface serial 1:23, and so on. The second PRI port configuration is not shown in this example. This Cisco AS5300 access server is used as part of a stack group dial-in solution for an Internet service provider.

Router# configure terminal

Router(config)# controller t1 0

Router(config-controller)# framing esf

Router(config-controller)# linecode b8zs

Router(config-controller)# clock source line primary

Router(config-controller)# pri-group timeslots 1-24

Router(config-controller)# exit

Router(config)# interface serial 0:23

Router(config-if)# ip unnumbered Loopback 0

Router(config-if)# ip accounting output-packets

Router(config-if)# no ip mroute-cache

Router(config-if)# encapsulation ppp

Router(config-if)# isdn incoming-voice modem

Router(config-if)# dialer-group 1

Router(config-if)# no fair-queue

Router(config-if)# compress stac

Router(config-if)# no cdp enable

Router(config-if)# ppp authentication chap

Router(config-if)# ppp multilink

Router(config-if)# netbios nbf

Line Types

This section describes the different line types used for dial access. It also describes the relationship between lines and interfaces.

Note Cisco devices have four types of lines: console, auxiliary, asynchronous, and virtual terminal. Different routers have different numbers of these line types. Refer to the hardware and software configuration guides that shipped with your device for exact configurations.

shows the types of lines that can be configured.

Table 1 Available Line Types

Line Type

Interface

Description

Numbering Rules

CON or CTY

Console

Typically used to log in to the router for configuration purposes.

Line 0.

AUX

Auxiliary

EIA/TIA-232 data terminal equipment (DTE) port used as a backup (tty) asynchronous port. Cannot be used as a second console port.

Last tty line number plus 1.

tty

Asynchronous

Same as asynchronous interface. Used typically for remote-node dial-in sessions that use such protocols as SLIP, PPP, AppleTalk Remote Access (ARA), and XRemote.

The numbering widely varies between platforms. This number is equivalent to the maximum number of modems or asynchronous interfaces supported by your access server or router.1

vty

Virtual asynchronous

Used for incoming Telnet, LAT, X.25 PAD, and protocol translation connections into synchronous ports (such as Ethernet and serial interfaces) on the router.

Last tty line number plus 2 through the maximum number of vty lines specified.2

1.Enter the interface line tty ? command to view the maximum number of tty lines supported.

1.Enter the interface line tty ? command to view the maximum number of tty lines supported.

2.Increase the number of vty lines on a router using the line vty global configuration command. Delete vty lines with the no line vty line-number command. The line vty command accepts any line number larger than 5 up to the maximum number of lines supported by your router with its current configuration. Enter the interface line vty ? command to view the maximum number of vty lines supported.

2.Increase the number of vty lines on a router using the line vty global configuration command. Delete vty lines with the no line vty line-number command. The line vty command accepts any line number larger than 5 up to the maximum number of lines supported by your router with its current configuration. Enter the interface line vty ? command to view the maximum number of vty lines supported.

command to see the status of each of the lines available on a router. (See Figure 10.)

Figure 10 Sample Show Line Output Showing CTY, tty, AUX, and vty Line Statistics

Relationship Between Lines and Interfaces

The following sections describe the relationship between lines and interfaces:

- Asynchronous Interfaces and Physical Terminal Lines

- Synchronous Interfaces and Virtual Terminal Lines

Asynchronous Interfaces and Physical Terminal Lines

Asynchronous interfaces correspond to physical terminal lines. Commands entered in asynchronous interface mode let you configure protocol-specific parameters for asynchronous interfaces; commands entered in line configuration mode let you configure the physical aspects of the line port.

For example, to enable IP resources to dial in to a network through a Cisco 2500 series access server, configure the lines and asynchronous interfaces as follows.

- Configure the physical aspect of a line that leads to a port. You might enter the following commands to configure lines 1 through 16 (asynchronous physical terminal lines on a Cisco 2511 access server):

line 1 16

login local

modem inout

speed 115200

flowcontrol hardware

! Configures the line to autosense PPP; physical line attribute.

autoselect ppp

- On asynchronous interface 1, you configure your protocol-specific commands. You might enter the following commands:

interface async 1

encapsulation ppp

async mode interactive

async dynamic address

async dynamic routing

async default ip address 192.168.16.132

ppp authentication chap

The remote node services SLIP, PPP, and XRemote are configured in asynchronous interface mode. ARA is configured in line configuration mode on virtual terminal lines or physical terminal lines.

Synchronous Interfaces and Virtual Terminal Lines

port on an interface. You can have multiple virtual ports for each synchronous interface.

For example, several Telnet connections can be made to an interface (such as an Ethernet or serial interface).

global configuration command.

Encapsulation Types

for a complete list and description of these encapsulation methods.

The following list summarizes the encapsulation commands available for serial interfaces used in dial configurations:

- encapsulation frame-relay —Frame Relay

- encapsulation hdlc —HDLC protocol

- enapsulation lapb —X.25 LAPB DTE operation

- enapsulation ppp —PPP

- encapsulation slip —SLIP

To use SLIP or PPP encapsulation, the router or access server must be configured with an IP routing protocol.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2007–2009 Cisco Systems, Inc. All rights reserved.