Table Of Contents
Dynamic Multiple Encapsulations
for Dial-In over ISDNDial-on-Demand Routing Software Enhancements
Dynamic, Multiple Encapsulations
Frame Relay Support on the Dialer Interface
MLP Encapsulation Enhancements
More Efficient ISDN Call Screening
Fancy Queueing and Traffic Shaping
Outbound Circuit-Switched X.25 Support over a Dialer Interface
DNIS-Plus-ISDN-Subaddress Multiple Call Binding Strategy
Related Features and Technologies
Supported Standards, MIBs, and RFCs
Configuring DNIS-plus-ISDN-Subaddress Binding
Verifying the Dynamic Multiple Encapsulations Feature
Multiple Encapsulations over ISDN
Outbound Circuit-Switched X.25
Frame Relay Encapsulation on a Main Interface
Frame Relay Encapsulation on a Subinterface
Sample Output with DNIS Binding
Dynamic Multiple Encapsulations
for Dial-In over ISDN
This document describes the Dynamic Multiple Encapsulations for Dial-In over ISDN feature. It includes the following sections:
•
Supported Standards, MIBs, and RFCs
Feature Overview
The Dynamic Multiple Encapsulations feature allows incoming calls over ISDN to be assigned an encapsulation type such as Frame Relay, PPP, and X.25 based on calling line identification (CLID) or DNIS. It also allows various encapsulation types and per-user configurations on the same ISDN B channel at different times according to the type of incoming call.
The Dynamic Multiple Encapsulations feature allows per-user configuration for each dial-in caller on any ingress ISDN B channel on which encapsulation can be run independently from other
B channels on the same ISDN link. The caller is identified by CLID or DNIS to ensure that only incoming calls with authorization and valid user profiles are accepted. When PPP is used, authentication and profile binding can also be done by PPP name.In addition, a large set of user profiles can be stored in dialer profiles locally or on a remote AAA server. (For large scale dial-in, storing user-specific configurations on a remote server becomes necessary for enhancing expandability and local memory efficiency.) However, whether stored locally or on a remote AAA server, the user-specific encapsulation and configuration can be applied to individual B channels dynamically and independently.
Dynamic multiple encapsulation is especially important in Europe where ISDN is relatively inexpensive and maximum use of all 30 B channels on the same ISDN link is desirable. Further, the feature removes the need to statically dedicate channels to a particular encapsulation and configuration type, and improves channel usage.
shows a typical configuration for an X.25 network in Europe. The Dynamic Multiple Encapsulations feature allows use of all 30 B channels, and supports calls that originate in diverse areas of the network and converge on the same ISDN PRI.
Figure 1 European X.25 Network
Although the Dynamic Multiple Encapsulations feature enhances large-scale dial-in functionality, the feature also works well in smaller-scale dial-in situations.
Dial-on-Demand Routing Software Enhancements
The following sections describe the enhancements to the dial-on-demand routing (DDR) software that enable the Dynamic Multiple Encapsulations feature.
Dynamic, Multiple Encapsulations
Before Cisco IOS software Release 12.0(7)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. 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.
For X.25 encapsulations, the configurations reside on the dialer profile. Dynamic multiple encapsulations provide support for PAD traffic and X.25 encapsulated and switched packets.
New Dialer Profile Model
In previous Cisco IOS software releases, 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, 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 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.
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.
However, the configuration on this found dialer profile could be different from the one on the D interface. For example, the ppp 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 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.
New Virtual Profile Model
The changes to the virtual profile model are similar to those for the new dialer profile model. If a B interface is bound by CLID to a created virtual access interface cloned from a virtual profile or a virtual template interface, only the configuration from the virtual profile or the virtual template takes effect. The configuration on the D interface is ignored unless successful binding occurs by PPP name. Both the link and network protocols run on the virtual access interface instead of the B channel, unless the encapsulation is PPP.
Additionally, the old virtual profile model supported only PPP encapsulations. The new virtual profile model in Cisco IOS Release 12.0(7)T supports HDLC, LAPB, X.25, and Frame Relay encapsulations. Any commands for these encapsulations that can be configured under a serial interface can be configured under a virtual profile stored in a user file on an AAA server and a virtual profile virtual template configured locally. The AAA server daemon downloads the commands as text to the network access server, and is able to handle multiple download attempts.
Moreover, in the old virtual profile model, downloading a profile from an AAA server and creating and cloning a virtual access interface were always done after the PPP call answer and LCP up processes. The AAA download is part of authorization. But in the new model, these operations must be performed before the call is answered and the link protocol goes up. This is a new AAA nonauthenticated authorization step. The virtual profile code handles multiple download attempts, and identifies whether a virtual access interface was cloned from a downloaded virtual profile.
When a download succeeds through nonauthenticated authorization, and the configuration on the virtual profile has encapsulation PPP and PPP authentication, authentication is negotiated as a separate step after LCP comes up.
Frame Relay Support on the Dialer Interface
lists the Frame Relay features that are supported by the Dynamic Multiple Encapsulations feature in Cisco IOS software release 12.0(7)T. This feature supports at least four Frame Relay PVCs on two dialer interfaces and subinterfaces.
Note
See the sections "Frame Relay Encapsulation on a Main Interface" and "Frame Relay Encapsulation on a Subinterface" in "Configuration Examples" for examples of Frame Relay encapsulations with the Dynamic Multiple Encapsulations feature.
MLP Encapsulation Enhancements
Previously, 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 the current software enhancements available in Cisco IOS
Release 12.0(7)T, 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.More Efficient ISDN Call Screening
Before the Dynamic Multiple Encapsulations feature, calls were screened in the ISDN process. ISDN accepted all synchronous calls and performed some minimal CLID screening before accepting or rejecting a call. With the Dynamic Multiple Encapsulations feature, DDR provides a separate process that screens for the profile of the caller. The new screening process also checks that enough resources are available to accept the call and that the call conforms to predetermined rules. When the call is found acceptable, the screening process searches for a matching profile for the caller. The call is accepted only when there is a matching profile.
Fancy Queueing and Traffic Shaping
In the old dialer profile model, fancy queueing and traffic shaping were configured under the physical interfaces. For ISDN, this was the D interface. Thus, the same queueing or traffic shaping scheme needed to be applied to all users that were sharing the same ISDN link.
The new dialer profile model moves all the per-user encapsulation configuration 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. 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. 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.
Outbound Circuit-Switched X.25 Support over a Dialer Interface
Cisco IOS software Release 12.0(5)T enabled circuit-switched X.25 clients—PAD, X.25 switching, and QLLC—to initiate calls and dynamically bring the X.25 context (which runs the X.25 protocol) up or down as needed. This capability allowed packet-switched traffic over a digital link like ISDN.
Before Release 12.0(5)T, X.25 circuit-switched clients were required to perform 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.
See the section "Outbound Circuit-Switched X.25" in "Configuration Examples" for an example of how to set up this feature.
Load Balancing
The Dynamic Multiple Encapsulations feature continues to support load balancing for the HDLC and PPP encapsulations, but not for LAPB, X.25, or Frame Relay. Load balancing is a Cisco-proprietary feature that brings up additional channels to handle intense packet traffic when a traffic threshold is configured with the dialer load-threshold command.
Note
DNIS-Plus-ISDN-Subaddress Multiple Call Binding Strategy
Previous releases of the DDR software allowed only one bind between a dialer profile and an ISDN B channel. If DNIS binding was used over an ISDN link, and only one dialer profile interface was configured with this DNIS, no other ISDN B channels could bind to the dialer profile interface after it was bound to another B channel because DNIS is not a user identification.
To overcome this problem, Cisco IOS Release 12.0(4)T provided a new dialer called command that allows DNIS-plus-ISDN-subaddress binding for the dialer profile in which the ISDN subaddress is a user identification. DNIS binding is allowed only when the ISDN subaddress is present in an incoming call and configured in a dialer profile. ISDN subaddresses are used mainly in Europe and Australia.
The list of authorized CLIDs and DNIS-plus-ISDN-subaddresses for each user is stored in a local dialer profile. The highest binding priority is configured as follows:
1
2
3
4
Benefits
•
•
•
B channels dynamically and independently.•
•
•
Restrictions
The Dynamic Multiple Encapsulations feature provides bidirectional support of all serial encapsulations except Frame Relay.
This feature also supports IP and IPX fast switching for HDLC and PPP encapsulations. There is no fast switching for LAPB, X.25, or Frame Relay; packets encapsulated by these protocols are always process switched.
Related Features and Technologies
The Dynamic Multiple Encapsulations feature changes the behavior of the DDR software functionality and serial line encapsulation. See the documents listed in the section "Related Documents" for background information about DDR and encapsulation methods.
Related Documents
For related information on the Dynamic Multiple Encapsulations feature, refer to the following documents:
•
Cisco IOS Release 12.0•
•
Supported Platforms
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Supported Standards, MIBs, and RFCs
Standards
None
MIBs
No new or modified MIBs are supported by this feature.
For descriptions of supported MIBs and how to use MIBs, see the Cisco MIB web site on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
RFCs
None
Prerequisites
Before beginning the configuration tasks in this document, you must:
•
•
See the documents listed in the section "Related Documents" for additional references.
Configuration Tasks
The Dynamic Multiple Encapsulations feature requires no new command to configure. It introduces new dialer profile behaviors over ISDN, rather than new configuration tasks. The only command added, dialer called, is not for configuring the Dynamic Multiple Encapsulations feature, but for configuring DNIS-plus-ISDN-subaddress profile binding.
To understand how dialer profiles work and how to configure them, see the Cisco IOS Release 12.0 Dial Solutions Configuration Guide and its chapters "Configuring Peer-to-Peer DDR with Dialer Profiles" and "Enterprise Dial Scenarios & Configurations." To understand the changes that the Dynamic Multiple Encapsulations feature and the Cisco IOS Release 12.0(4)T, 12.0(5)T, and 12.0(7)T software have made to the dialer profile model, see the section "Dial-on-Demand Routing Software Enhancements" earlier in this document.
To configure DNIS-plus-ISDN-subaddress binding, if appropriate for your network, perform the task described in the section "Configuring DNIS-plus-ISDN-Subaddress Binding" later in this document.
To verify that the Dynamic Multiple Encapsulations feature is operating, view the physical interface bindings in effect as a result of the Dynamic Multiple Encapsulations feature. This task is described in the section "Verifying the Dynamic Multiple Encapsulations Feature" later in this document.
Configuring DNIS-plus-ISDN-Subaddress Binding
To configure DNIS-plus-ISDN-subaddress binding, use the following command in dial-on-demand routing mode, which allows multiple binds between a dialer profile and an ISDN B channel. This configuration requires an ISDN subaddress, which is used in Europe and Australia.
Verifying the Dynamic Multiple Encapsulations Feature
To verify dialer interfaces configured for binding and see statistics on each physical interface bound to the dialer interface, use the show interfaces EXEC command. Look for the reports "Bound to:" and "Interface is bound to..." and remember that this feature only applies to ISDN.
Router# show interfaces dialer0Dialer0 is up, line protocol is upHardware is UnknownInternet address is 21.1.1.2/8MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255Encapsulation PPP, loopback not setDTR is pulsed for 1 seconds on resetInterface is bound to BRI0:1Last input 00:00:38, output never, output hang neverLast clearing of "show interface" counters 00:05:36Queueing strategy: fifoOutput queue 0/40, 0 drops; input queue 0/75, 0 drops5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 0 bits/sec, 0 packets/sec38 packets input, 4659 bytes34 packets output, 9952 bytesBound to:BRI0:1 is up, line protocol is upHardware is BRIMTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255Encapsulation PPP, loopback not set, keepalive not setInterface is bound to Dialer0 (Encapsulation PPP)LCP Open, multilink OpenLast input 00:00:39, output 00:00:11, output hang neverLast clearing of "show interface" counters neverQueueing strategy: fifoOutput queue 0/40, 0 drops; input queue 0/75, 0 drops5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 0 bits/sec, 0 packets/sec78 packets input, 9317 bytes, 0 no bufferReceived 65 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort93 packets output, 9864 bytes, 0 underruns0 output errors, 0 collisions, 7 interface resets0 output buffer failures, 0 output buffers swapped out4 carrier transitionsAt the end of 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 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:1BRI0:1 is up, line protocol is upHardware is BRIMTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255Encapsulation PPP, loopback not set, keepalive not setInterface is bound to Dialer0 (Encapsulation LAPB)LCP Open, multilink OpenLast input 00:00:31, output 00:00:03, output hang neverLast clearing of "show interface" counters neverQueueing strategy: fifoOutput queue 0/40, 0 drops; input queue 0/75, 0 drops5 minute input rate 0 bits/sec, 1 packets/sec5 minute output rate 0 bits/sec, 1 packets/sec110 packets input, 13994 bytes, 0 no bufferReceived 91 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort135 packets output, 14175 bytes, 0 underruns0 output errors, 0 collisions, 12 interface resets0 output buffer failures, 0 output buffers swapped out8 carrier transitionsAny protocol configuration and states should be displayed from the dialer 0 interface.
Configuration Examples
This section provides the following configuration examples:
•
•
•
•
Multiple Encapsulations over ISDN
In the following configuration example, a network access server named NAS1 has 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.
When an ISDN B channel connects to remote user RU2 using CLID 60043, Dialer1 is bound to this ISDN B channel by CLID binding. The protocol used is PPP; the X.25 configuration on the 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.
The Dialer2 interface uses DNIS-plus-ISDN-subaddress binding, and is bound to a B channel with an incoming call with DNIS 60045 and ISDN subaddress 12345. Also note that the HDLC encapsulation has no username associated. It is no longer necessary to configure the dialer remote-name 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 12.0(4)Tservice timestamps debug datetime msecservice timestamps log datetime msecservice password-encryptionservice udp-small-serversservice tcp-small-servers!virtual-profile virtual-template 1virtual-profile aaa!hostname NAS1!aaa new-modelaaa authentication ppp default radiusaaa authorization network radiusenable secret 5 $1$0Ced$YYJJl2p8f94lc/.JSgw8n1enable password 7 153D19270D2E!username RU1 password 7 11260B2E1E16username RU2 password 7 09635C221001no ip domain-lookupip domain-name cisco.comip name-server 198.92.30.32ip name-server 171.69.2.132isdn switch-type basic-5ess!int Virtual-Template 1encapsulation pppppp authentication chap!interface Ethernet0ip address 172.21.17.11 255.255.255.0no ip mroute-cacheno cdp enable!interface Serial0ip address 2.2.2.1 255.0.0.0shutdownclockrate 56000ppp authentication chap!interface Serial1ip address 10.0.0.1 255.0.0.0shutdown!interface BRI0description PBX 60035no ip addressencapsulation x25no ip mroute-cacheno keepalivedialer pool-member 1dialer pool-member 2!interface Dialer0ip address 21.1.1.1 255.0.0.0encapsulation lapb dce multino ip route-cacheno ip mroute-cacheno keepalivedialer remote-name RU1dialer idle-timeout 300dialer string 60036dialer caller 60036dialer pool 1dialer-group 1no fair-queue!interface Dialer1ip address 22.1.1.1 255.0.0.0encapsulation pppno ip route-cacheno ip mroute-cachedialer remote-name RU2dialer string 60043dialer caller 60043dialer pool 2dialer-group 1no fair-queueno cdp enableppp authentication chap!interface Dialer2ip address 23.1.1.1 255.0.0.0encapsulation hdlcdialer called 60045:12345dialer pool 1dialer-group 1fair-queue!radius-server host 171.69.61.87radius-server key foobarsnmp-server community public RO!line con 0exec-timeout 0 0line aux 0transport input allline vty 0 4password 7 10611B320C13login!endOutbound Circuit-Switched X.25
The following example shows how to configure dynamic X.25 on an ISDN interface. illustrates the configuration.
Figure 2 Dynamic X.25 over ISDN
Configuration for Yen:
version 12.0(5)Tservice timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice udp-small-serversservice tcp-small-servers!hostname yen!enable secret 5 $1$K32j$4AZW2oMDivpUeuMa/Fdcd.enable password poPPee!username mark password 0 ciscousername dinar password 0 ciscoip subnet-zerono ip domain-lookupip domain-name cicso.comip name-server 171.69.1.148!isdn switch-type basic-5essx25 routing!interface Loopback0no ip addressno ip directed-broadcastno ip mroute-cache!interface Ethernet0ip address 172.21.75.2 255.255.255.0no ip directed-broadcastno ip mroute-cachemedia-type 10BaseT!interface BRI1no ip addressno ip directed-broadcastno ip mroute-cachedialer pool-member 1isdn switch-type basic-5essno fair-queue!interface Dialer0ip address 2.1.1.1 255.0.0.0no ip directed-broadcastencapsulation x25no ip mroute-cachedialer remote-name dinardialer idle-timeout 180dialer string 81060dialer caller 81060dialer max-call 1dialer pool 1dialer-group 1x25 address 11111x25 map ip 2.1.1.2 22222!ip default-gateway 172.21.75.1no ip classlessip route 0.0.0.0 0.0.0.0 172.21.75.1no ip http server!access-list 101 permit ip any anydialer-list 1 protocol ip list 101!x25 route 22222 interface Dialer0x25 route 33333 interface Dialer0!line con 0exec-timeout 0 0transport input noneline aux 0transport input allline vty 0 4password ciscologinline vty 5 100password ciscologin!endConfiguration for Peso Acting as X.25 Switch:
version 12.0(5)Tservice timestamps debug uptimeservice timestamps log uptimeno service password-encryption!hostname peso!enable secret 5 $1$.Q00$h3vIhbOwO1fPvA2LYx2gE.enable password cisco!ip subnet-zero!isdn switch-type primary-5essx25 routing!controller T1 0cablelength shortcablelength short 133!controller T1 1framing esfclock source line primarypri-group timeslots 1-24!controller T1 2cablelength shortcablelength short 133!controller T1 3cablelength shortcablelength short 133!interface Ethernet0ip address 172.21.75.3 255.255.255.0no ip directed-broadcast!interface Serial1:23no ip addressno ip directed-broadcastencapsulation pppdialer pool-member 1isdn switch-type primary-5essisdn incoming-voice modemno fair-queueno cdp enableppp authentication chap!interface Dialer0no ip addressno ip directed-broadcastencapsulation x25 dceno ip mroute-cachedialer remote-name yendialer idle-timeout 180dialer string 61401dialer caller 61401dialer max-call 1dialer pool 1x25 address 33333!interface Dialer1no ip addressno ip directed-broadcastencapsulation x25 dceno ip mroute-cachedialer remote-name dinardialer idle-timeout 180dialer string 61403dialer caller 61403dialer max-call 1dialer pool 1x25 address 44444!ip default-gateway 172.21.75.1no ip classlessip route 0.0.0.0 0.0.0.0 172.21.75.1no ip http server!x25 route 11111 interface Dialer0x25 route 22222 interface Dialer1x25 route source 11111 interface Dialer1x25 route input-interface Dialer0 interface Dialer1!line con 0transport input noneline 1 48line aux 0line vty 0 4password ciscologinline vty 5 100password ciscologin!endConfiguration for Dinar:
version 12.0(5)Tservice timestamps debug uptimeservice timestamps log uptimeno service password-encryption!hostname dinar!logging buffered 16384 debuggingenable secret 5 $1$8EjF$4.S0AoMOVa5OIAYEMrrFI/enable password cisco!username yen password 0 ciscousername 7701username drachma password 0 ciscousername AODI password 0 ciscoip subnet-zeroip rcmd rcp-enableip rcmd rsh-enableip rcmd remote-username atirumal!isdn switch-type basic-5essx25 routing!controller T1 0/0!interface BRI3/1no ip addressno ip directed-broadcastno ip mroute-cachedialer pool-member 1isdn switch-type basic-5essno fair-queue!interface Dialer0ip address 2.1.1.2 255.0.0.0no ip directed-broadcastencapsulation x25no ip mroute-cachedialer remote-name yendialer idle-timeout 180dialer string 81060dialer caller 81060dialer max-call 1dialer pool 1dialer-group 1x25 address 22222x25 map ip 2.1.1.1 11111!interface Dialer1ip address 6.1.1.10 255.0.0.0no ip directed-broadcastno ip mroute-cachedialer in-banddialer-group 1no fair-queue!ip default-gateway 172.21.75.1no ip classlessip route 0.0.0.0 0.0.0.0 172.21.75.1no ip http server!access-list 101 permit ip any anydialer-list 1 protocol ip list 101!x25 route 11111 interface Dialer0x25 route 44444 interface Dialer0!Frame Relay Encapsulation on a Main Interface
The following example shows a configuration for Frame Relay encapsulation on a main interface.
version 12.0(7)Tservice timestamps debug datetime msecservice timestamps log datetime msecno service password-encryption!hostname honda!ip subnet-zeroip domain-name cisco.comip name-server 171.69.2.132ip name-server 198.92.30.32!isdn switch-type basic-5ess!interface Loopback1no ip addressno ip directed-broadcast!interface Ethernet0ip address 172.21.17.18 255.255.255.0no ip directed-broadcastno ip route-cacheno ip mroute-cachemedia-type 10BaseTno cdp enable!interface BRI0description PBX 60043no ip addressno ip directed-broadcastno keepalivedialer pool-member 10 max-link 1isdn switch-type basic-5essno fair-queue!interface Dialer10ip address 8.1.1.1 255.255.255.0no ip directed-broadcastencapsulation frame-relaydialer remote-name audidialer string 60035dialer caller 60035dialer max-call 1dialer pool 10dialer-group 1no fair-queuepulse-time 0frame-relay map ip 8.1.1.2 200!dialer-list 1 protocol ip permitdialer-list 1 protocol ipx permit!ip default-gateway 172.21.17.1ip classlessip route 0.0.0.0 0.0.0.0 172.21.17.1no ip http server!line con 0transport input noneline aux 0line vty 0 4login!endFrame Relay Encapsulation on a Subinterface
The following example shows a configuration for Frame Relay encapsulation on a subinterface.
!version 12.0(7)Tservice timestamps debug datetime msecservice timestamps log datetime msecno service password-encryption!hostname honda!interface Loopback1no ip addressno ip directed-broadcast!interface Ethernet0ip address 172.21.17.18 255.255.255.0no ip directed-broadcastno ip route-cacheno ip mroute-cachemedia-type 10BaseTno cdp enable!interface BRI0description PBX 60043no ip addressno ip directed-broadcastno keepalivedialer pool-member 10 max-link 1isdn switch-type basic-5essno fair-queueno cdp enable!interface Dialer10ip address 8.1.1.1 255.0.0.0no ip directed-broadcastencapsulation frame-relaydialer remote-name audidialer string 60035dialer caller 60035dialer max-call 1dialer pool 10dialer-group 1no fair-queuepulse-time 0!interface Dialer10.1 point-to-pointip address 1.1.1.1 255.0.0.0no ip directed-broadcastframe-relay interface-dlci 100!interface Dialer10.2 multipointip address 2.1.1.1 255.0.0.0no ip directed-broadcastframe-relay interface-dlci 200!ip default-gateway 172.21.17.1ip classlessip route 0.0.0.0 0.0.0.0 172.21.17.1no ip http server!dialer-list 1 protocol ip permitdialer-list 1 protocol ipx permit!line con 0transport input noneline aux 0line vty 0 4login!endCommand Reference
This section documents the following new and modified commands that configure the Dynamic Multiple Encapsulations feature. All other commands used with this feature are documented in the Cisco IOS Release 12.0 command reference publications.
In Cisco IOS Release 12.0(1)T or later, you can search and filter the output for show and more commands. This functionality is useful when you need to sort through large amounts of output, or if you want to exclude output that you do not need to see.
To use this functionality, enter a show or more command followed by the "pipe" character (|), one of the keywords begin, include, or exclude, and an expression that you want to search or filter on:
command | {begin | include | exclude} regular-expression
Following is an example of the show atm vc command in which you want the command output to begin with the first line where the expression "PeakRate" appears:
show atm vc | begin PeakRate
For more information on the search and filter functionality, refer to the Cisco IOS Release 12.0(1)T feature module titled CLI String Search.
dialer called
To configure dial-on-demand routing (DDR) to perform DNIS-plus-ISDN-subaddress binding for dialer profile interfaces, use the dialer called dial-on-demand routing configuration command. To disable DNIS-plus-ISDN-subaddress binding, use the no form of this command.
dialer called DNIS:subaddress
no dialer called DNIS:subaddress
Syntax Description
DNIS:subaddress
Dialed Number Identification Service, or the called party number, a colon, and the ISDN subaddress.
Defaults
No default behavior or values.
Command Modes
Dial-on-demand routing
Command History
Usage Guidelines
If you have more than one DNIS-plus-ISDN-subaddress number to configure under the same dialer profile interface, you can configure multiple dialer called commands.
The parser accepts a dialer called command with a DNIS and without the subaddress; however, the call will fail. For a successful call, enter the DNIS, a colon, and the ISDN subaddress after the dialer called command.
Examples
The following example configures a dialer profile for a receiver with DNIS 12345 and ISDN subaddress 6789:
dialer called 12345:6789Related Commands
dial caller
Configures caller ID screening and enables ISDN caller ID callback for the dialer profiles DDR feature.
show interfaces
To display statistics for all interfaces configured on the router or access server, use the show interfaces EXEC command. The resulting output varies, depending on the network for which an interface has been configured.
show interfaces [type number] [first] [last] [accounting]
show interfaces [type slot/port] [accounting] (for Cisco 7200 series routers, and for
Cisco 7500 series routers with a Packet-over-SONET Interface Processor)show interfaces [type slot/port-adapter/port] [ethernet | serial] (for ports on a Versatile
Interface Processor (VIP) in Cisco 7500 series routers)Syntax Description
Defaults
Statistical display of all network interfaces.
Command Modes
EXEC
Command History
Cisco IOS Release 10.0
This command was introduced.
Cisco IOS Release 12.0(4)T
The display was enhanced to report dialer bound interfaces.
Usage Guidelines
The report from this command for the Cisco 7200 series routers shows the interface processors in slot order. If you add interface processors after booting the system, they will appear at the end of the list, in the order in which they were inserted.
If you use the show interfaces command on the Cisco 7200 series routers without the slot/port arguments, information for all interface types will be shown. For example, if you use show interfaces ethernet you will receive information for all Ethernet, FDDI, serial, and Token Ring interfaces. Only by adding the type slot/port argument can you specify a particular interface.
If you use the show interfaces command for an interface type that has been removed from the router or access server, interface statistics will be displayed accompanied by the following text: "Hardware has been removed."
If you use the show interfaces command on a router or access server for which interfaces are configured to use weighted fair queueing through the fair-queue interface command, additional information is displayed containing the current and high-water mark number of flows.
If you use the show interfaces command on dialer interfaces configured for binding, the display will report statistics on each physical interface bound to the dialer interface; see the following examples for more information.
You will use the show interfaces command frequently while configuring and monitoring devices. The various forms of the show interfaces commands are described in detail in the following sections.
Examples
The following is sample output from the show interfaces command. Because your display will depend on the type and number of interface cards in your router or access server, only a portion of the output is shown.
Router# show interfacesEthernet 0 is up, line protocol is upHardware is MCI Ethernet, address is 0000.0c00.750c (bia 0000.0c00.750c)Internet address is 131.108.28.8, subnet mask is 255.255.255.0MTU 1500 bytes, BW 10000 Kbit, DLY 100000 usec, rely 255/255, load 1/255Encapsulation ARPA, loopback not set, keepalive set (10 sec)ARP type: ARPA, ARP Timeout 4:00:00Last input 0:00:00, output 0:00:00, output hang neverLast clearing of "show interface" counters 0:00:00Output queue 0/40, 0 drops; input queue 0/75, 0 dropsFive minute input rate 0 bits/sec, 0 packets/secFive minute output rate 2000 bits/sec, 4 packets/sec1127576 packets input, 447251251 bytes, 0 no bufferReceived 354125 broadcasts, 0 runts, 0 giants0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort5332142 packets output, 496316039 bytes, 0 underruns0 output errors, 432 collisions, 0 interface resets, 0 restarts---More---Sample Output with DNIS Binding
When the show interfaces command is issued on an unbound dialer interface, the output looks as follows:
Router# show interfaces dialer0Dialer0 is up (spoofing), line protocol is up (spoofing)Hardware is UnknownInternet address is 21.1.1.2/8MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 3/255Encapsulation PPP, loopback not setDTR is pulsed for 1 seconds on resetLast input 00:00:34, output never, output hang neverLast clearing of "show interface" counters 00:05:09Queueing strategy: fifoOutput queue 0/40, 0 drops; input queue 0/75, 0 drops5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 1000 bits/sec, 0 packets/sec18 packets input, 2579 bytes14 packets output, 5328 bytesBut when the show interfaces command is issued on a bound dialer interface, you will get an additional report indicating the binding relationship. The output looks as follows:
Router# show interfaces dialer0Dialer0 is up, line protocol is upHardware is UnknownInternet address is 21.1.1.2/8MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255Encapsulation PPP, loopback not setDTR is pulsed for 1 seconds on resetInterface is bound to BRI0:1Last input 00:00:38, output never, output hang neverLast clearing of "show interface" counters 00:05:36Queueing strategy: fifoOutput queue 0/40, 0 drops; input queue 0/75, 0 drops5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 0 bits/sec, 0 packets/sec38 packets input, 4659 bytes34 packets output, 9952 bytesBound to:BRI0:1 is up, line protocol is upHardware is BRIMTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255Encapsulation PPP, loopback not set, keepalive not setInterface is bound to Dialer0 (Encapsulation PPP)LCP Open, multilink OpenLast input 00:00:39, output 00:00:11, output hang neverLast clearing of "show interface" counters neverQueueing strategy: fifoOutput queue 0/40, 0 drops; input queue 0/75, 0 drops5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 0 bits/sec, 0 packets/sec78 packets input, 9317 bytes, 0 no bufferReceived 65 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort93 packets output, 9864 bytes, 0 underruns0 output errors, 0 collisions, 7 interface resets0 output buffer failures, 0 output buffers swapped out4 carrier transitionsAt the end of Dialer0 output, 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 Dialer0 and 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:1BRI0:1 is up, line protocol is upHardware is BRIMTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255Encapsulation PPP, loopback not set, keepalive not setInterface is bound to Dialer0 (Encapsulation LAPB)LCP Open, multilink OpenLast input 00:00:31, output 00:00:03, output hang neverLast clearing of "show interface" counters neverQueueing strategy: fifoOutput queue 0/40, 0 drops; input queue 0/75, 0 drops5 minute input rate 0 bits/sec, 1 packets/sec5 minute output rate 0 bits/sec, 1 packets/sec110 packets input, 13994 bytes, 0 no bufferReceived 91 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort135 packets output, 14175 bytes, 0 underruns0 output errors, 0 collisions, 12 interface resets0 output buffer failures, 0 output buffers swapped out8 carrier transitionsAny protocol configuration and states should be displayed from the Dialer0 interface.
virtual-profile aaa
To enable virtual profiles by authentication, authorization, and accounting (AAA) configuration, use the virtual-profile aaa global configuration command. To disable virtual profiles, use the no form of this command.
virtual-profile aaa
no virtual-profile aaa
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Global configuration
Command History
Usage Guidelines
Effect of this command for any specific user depends on the router being configured for AAA and the AAA server being configured for the specific configuration information of that user.
Examples
The following example configures virtual profiles by AAA configuration only:
virtual-profile aaaRelated Commands
aaa authentication
Enables AAA authentication.
virtual-profile virtual-template
Enables virtual profiles by virtual interface template.
Glossary
AAA—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.
Asynchronous Transfer Mode—See ATM.
ATM—Asynchronous Transfer Mode. International standard for cell relay in which multiple service types (such as voice, video, or data) are conveyed in fixed-length (53-byte) cells. Fixed-length cells allow cell processing to occur in hardware, thereby reducing transit delays. ATM is designed to take advantage of high-speed transmission media such as E3, SONET, and T3.
authentication, authorization, and accounting—See AAA.
calling line identification—See CLID.
CLID—calling line identification. A unique number that informs the called party of the phone number identification of the calling party. Also known as caller ID.
data circuit-terminating equipment—See DCE.
data terminal equipment—See DTE.
DCE—data circuit-terminating equipment (ITU-T expansion). Devices and connections of a communications network that comprise the network end of the user-to-network interface. The DCE provides a physical connection to the network, forwards traffic, and provides a clocking signal used to synchronize data transmission between DCE and DTE devices. Modems and interface cards are examples of DCE.
DDR—dial-on-demand routing. Technique whereby a router can automatically initiate and close a circuit-switched session as transmitting stations demand. The router spoofs keepalive messages so that end stations treat the session as active. DDR permits routing over ISDN or telephone lines using an external ISDN terminal adapter or modem.
DE bit—discard eligible bit. ATM cells can have this bit set to determine the probability of a cell being dropped if the network becomes congested.
Dialed Number Identification Service—See DNIS.
dialer profile—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. A dialer profile has 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, and an ordered dialer pool of physical interfaces to be used by the dialer interface.
dial-on-demand routing—See DDR.
DNIS—Dialed Number Identification Service. The called party number. Typically, this is a number used by call centers or a central office where different numbers are each assigned to a specific service.
DTE—data terminal equipment. Device at the user end of a user-network interface that serves as a data source, destination, or both. DTE connects to a data network through a DCE device (for example, a modem) and typically uses clocking signals generated by the DCE. DTE includes such devices as computers, protocol translators, and multiplexers.
Frame Relay—Industry-standard, switched data link layer protocol that handles multiple virtual circuits using HDLC encapsulation between connected devices. Frame Relay is more efficient than X.25, the protocol for which it is generally considered a replacement.
HDLC—High-Level Data Link Control. Popular ISO standard bit-oriented, link-layer protocol derived from the Synchronous Data Link Control Protocol. HDLC specifies an encapsulation method of data on synchronous serial data links.
High-Level Data Link Control—See HDLC.
Integrated Services Digital Network—See ISDN.
ISDN—Integrated Services Digital Network. Communication protocol, offered by telephone companies, that permits telephone networks to carry data, voice, and other source traffic.
LAPB-TA—Link Access Procedure, Balanced-terminal adapter. LAPB is a bit-oriented protocol derived from HDLC.
LCP—Link Control Protocol. Protocol that establishes, configures, and tests data-link connections for use by PPP.
Link Access Procedure, Balanced-terminal adapter—See LAPB-TA.
Link Control Protocol—See LCP.
LMI—Local Management Interface. Set of enhancements to the basic Frame Relay specification. LMI includes support for a keepalive mechanism, which verifies that data is flowing; a multicast mechanism, which provides the network server with its local DLCI and the multicast DLCI; global addressing, which gives DLCIs global rather than local significance in Frame Relay networks; and a status mechanism, which provides an ongoing status report on the DLCIs known to the switch. Known as LMT in ANSI terminology.
Local Management Interface—See LMI.
MLP—Multilink PPP. Method of splitting, recombining, and sequencing datagrams across multiple logical data links.
Multilink PPP—See MLP.
NCP—Network Control Protocol. Series of protocols for establishing and configuring different network layer protocols, such as for AppleTalk over PPP.
Network Control Protocol—See NCP.
packet assembler/disassembler—See PAD.
PAD—packet assembler/disassembler. Device used to connect simple devices (like character-mode terminals) that do not support the full functionality of a particular protocol to a network. PADs buffer data and assemble and disassemble packets sent to such end devices.
permanent virtual circuit—See PVC.
per-user configuration—Ties together virtual interfaces configuration, AAA per-user security, and virtual profiles to provide a flexible, scalable, easily maintained solution for large-scale dial-in networks.
Point-to-Point Protocol—See PPP.
PPP—Point-to-Point Protocol. Provides router-to-router and host-to-network connections over synchronous and asynchronous circuits. PPP also has built-in security mechanisms, such as the Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP). PPP relies on two protocols: LCP and NCP.
PVC—permanent virtual circuit or permanent virtual connection. Virtual circuit that is permanently established. PVCs save bandwidth associated with circuit establishment and tear down in situations where certain virtual circuits must exist all the time. In ATM terminology, called a permanent virtual connection.
Qualified Logical Link Control—See QLLC.
QLLC—Qualified Logical Link Control. Data link layer protocol defined by IBM that allows SNA data to be transported across X.25 networks.
RTP header compression—Real-Time Transport Protocol header compression. Compresses the IP/UDP/RTP header in an RTP data packet from 40 bytes to approximately 2 to 5 bytes. It is a hop-by-hop compression scheme similar to RFC 1144 for TCP header compression. RTP header compression is supported on serial lines using Frame Relay, HDLC, or PPP encapsulation. It is also supported over ISDN interfaces.
virtual access interface—Instance of a unique virtual interface that is created dynamically and exists temporarily. Virtual access interfaces can be created and configured differently by different applications, such as virtual profiles and virtual dialup networks.
virtual interface template—Generic configuration of an interface for a certain purpose or configuration common to certain users, plus router-dependent information. This configuration takes the form of a list of Cisco IOS interface commands to be applied to the virtual interface as needed. Several applications can apply virtual templates, but generally each application uses a single template. Each virtual template is identified by number.
virtual profile—A virtual profile defines and applies per-user configuration information for users that dial in to a router. Virtual profiles allow user-specific configuration information to be applied irrespective of the media used for the dial-in call. The configuration information for virtual profiles can come from a virtual interface template, per-user configuration information stored on an AAA server, or both, depending on how the router and AAA server are configured.
X.25—ITU-T standard that defines how connections between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) are maintained for remote terminal access and computer communications in public data networks (PDNs). X.25 specifies LAPB, a data link layer protocol, and packet level protocol (PLP), a network layer protocol.
Guest
